PS: Correction: If we hold the TEI Council meeting on that *day* of Tuesday 1/14, I won't be able to make it. (But I can attend on Thursday that week or the following Tuesday.) Thanks, Elisa On Thu, Jan 2, 2020 at 2:25 PM Elisa Beshero-Bondar wrote:

Syd--thanks for looking ahead at calendars about meetings! I need to tell everyone in confidence that I am doing an all-day campus job interview on Tuesday 1/14, so if we are holding the TEI Council meeting that week, I may not (meaning, almost certainly cannot) attend. Since Raff and I are release techs on the next release, and since I've been doing a lot of revisions in the past month to documentation that I want to ask the group about, I really don't want to miss this particular meeting! Can we move the meeting possibly to Thursday just that week (1/16), or by one week later, to Tuesday 1/21?

Thanks all! Elisa

On Thu, Jan 2, 2020 at 2:10 PM Bauman, Syd wrote:

...

[Originally sent Mon, 23 Dec 2019 09:51:27 -0500, but bounced due to a networking problem here with my Northeastern machine. You may notice that this is not a true reply, just a new e-mail with a subject line that looks like it is a reply. Sigh. Note that I will likely have trouble sending e-mail for some time to come.]

So, it sounds like we should move the January Stylesheets group meeting to Tue 21 Jan 20 at 14:00Z. That is: 06:00 PST 09:00 EST 14:00 GMT 15:00 CET (Do we have any other time zones represented on Council?)

Unless I hear strenuous objections pretty soon, we will plan on that.

I am likely to miss the Council meeting of Tue 14 Jan 20 14:00Z. (I will be traveling in London; depending on train schedules, my family, etc., I may be able to make it, but I am not counting on it.)

Whether I make it or not, I hope the topic of keeping the Docker containers updated is discussed. My thoughts on this topic follow, in no particular order.

* It is definitely important to keep the OS running in a Docker container up to date with security patches. It may not be as big a problem as Martin worries it is, especially if we are all vigilant in leaving a container running for the minimum amount of time necessary. But it is still important enough that we should have a process for doing it.

* The solution is probably administrative, not technical.

* It is probably unfair to insist that Peter and Hugh be solely responsible for doing this. (That said, if they don't object, I don't either. I would if it were only 1 person -- at least 2 people should know how to do everything that is even semi-important.) Could be a rotating responsibility.

* My suggested administrative idea: Once a month, 1-24 hours *before* the Council meeting, the Docker maintainer or designee should update each container with the latest OS security patches. (Chair should send a reminder 48 hours before the meeting.) Immediately *after* the Council meeting each Council member should download and install the updated container.

* Peter pointed out that doing such an update might break the build within the container. He's right, but that's no reason not to install security patches. It's a reason to fix the build process so it works on a properly updated system. Doing this on meeting day, I figure, gives us a higher chance of noticing a build fail, finding a fix, and promulgating the solution rapidly.

_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

-- Elisa Beshero-Bondar, PhD Director, Center for the Digital Text | Associate Professor of English University of Pittsburgh at Greensburg | Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8@pitt.edu Development site: http://newtfire.org

-- Elisa Beshero-Bondar, PhD Director, Center for the Digital Text | Associate Professor of English University of Pittsburgh at Greensburg | Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8@pitt.edu Development site: http://newtfire.org

Thursday, 16 Jan at 09:00 EST, 14:00 GMT, 15:00 CET will work for me. Best Peter

Am 06.01.2020 um 15:36 schrieb Scholger, Martina (martina.scholger@uni-graz.at) :

Dear all,

Our next Council meeting is scheduled for Tuesday, 14 January (09:00 EST, 14:00 GMT, 15:00 CET). Elisa said that she cannot make it that day and asked to move it to either Thursday, 16 Jan or Tuesday, 21 Jan. Since we already agreed to move the January Stylesheets meeting to Tuesday, 21 January, I would ask all of you to check if you are available on Thursday, 16 Jan at 09:00 EST, 14:00 GMT, 15:00 CET. Otherwise I would suggest to allocate the first 20-30 minutes of the Stylesheets meeting on 21 Jan to talking about the upcoming release with Elisa.

Best, Martina

Von: Tei-council Im Auftrag von Elisa Beshero-Bondar Gesendet: Donnerstag, 2. Januar 2020 20:28 An: Bauman, Syd Cc: tei-council@lists.tei-c.org Betreff: Re: [Tei-council] meetings and containers (was "Re: Stylesheets (and other) meeting time")

PS: Correction: If we hold the TEI Council meeting on that *day* of Tuesday 1/14, I won't be able to make it. (But I can attend on Thursday that week or the following Tuesday.) Thanks, Elisa

On Thu, Jan 2, 2020 at 2:25 PM Elisa Beshero-Bondar wrote: Syd--thanks for looking ahead at calendars about meetings! I need to tell everyone in confidence that I am doing an all-day campus job interview on Tuesday 1/14, so if we are holding the TEI Council meeting that week, I may not (meaning, almost certainly cannot) attend. Since Raff and I are release techs on the next release, and since I've been doing a lot of revisions in the past month to documentation that I want to ask the group about, I really don't want to miss this particular meeting! Can we move the meeting possibly to Thursday just that week (1/16), or by one week later, to Tuesday 1/21?

Thanks all! Elisa

On Thu, Jan 2, 2020 at 2:10 PM Bauman, Syd wrote: [Originally sent Mon, 23 Dec 2019 09:51:27 -0500, but bounced due to a networking problem here with my Northeastern machine. You may notice that this is not a true reply, just a new e-mail with a subject line that looks like it is a reply. Sigh. Note that I will likely have trouble sending e-mail for some time to come.]

So, it sounds like we should move the January Stylesheets group meeting to Tue 21 Jan 20 at 14:00Z. That is: 06:00 PST 09:00 EST 14:00 GMT 15:00 CET (Do we have any other time zones represented on Council?)

Unless I hear strenuous objections pretty soon, we will plan on that.

I am likely to miss the Council meeting of Tue 14 Jan 20 14:00Z. (I will be traveling in London; depending on train schedules, my family, etc., I may be able to make it, but I am not counting on it.)

Whether I make it or not, I hope the topic of keeping the Docker containers updated is discussed. My thoughts on this topic follow, in no particular order.

* It is definitely important to keep the OS running in a Docker container up to date with security patches. It may not be as big a problem as Martin worries it is, especially if we are all vigilant in leaving a container running for the minimum amount of time necessary. But it is still important enough that we should have a process for doing it.

* The solution is probably administrative, not technical.

* It is probably unfair to insist that Peter and Hugh be solely responsible for doing this. (That said, if they don't object, I don't either. I would if it were only 1 person -- at least 2 people should know how to do everything that is even semi-important.) Could be a rotating responsibility.

* My suggested administrative idea: Once a month, 1-24 hours *before* the Council meeting, the Docker maintainer or designee should update each container with the latest OS security patches. (Chair should send a reminder 48 hours before the meeting.) Immediately *after* the Council meeting each Council member should download and install the updated container.

* Peter pointed out that doing such an update might break the build within the container. He's right, but that's no reason not to install security patches. It's a reason to fix the build process so it works on a properly updated system. Doing this on meeting day, I figure, gives us a higher chance of noticing a build fail, finding a fix, and promulgating the solution rapidly.

_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

-- Elisa Beshero-Bondar, PhD Director, Center for the Digital Text | Associate Professor of English University of Pittsburgh at Greensburg | Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8@pitt.edu Development site: http://newtfire.org

-- Elisa Beshero-Bondar, PhD Director, Center for the Digital Text | Associate Professor of English University of Pittsburgh at Greensburg | Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8@pitt.edu Development site: http://newtfire.org _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

Of course Thursday 1/16 works for me next week, since I can’t attend on the 14th. I am really sorry about the interruption—I didn’t get a choice in timing this interview, so I appreciate everyone being a little flexible! Thanks all! Elisa Sent from my iPhone

On Jan 7, 2020, at 6:46 AM, Bauman, Syd wrote:

Thursday, 16 Jan at 09:00 EST, 14:00 GMT, 15:00 CET will work for me. Not convenient, but I would almost assuredly make it work. (Espeicially since I also probably cannot attend on Tue 14.)

That said, I think it perfectly reasonable to allow release discussion to usurp some or all of our Stylesheets meeting timeslot, if needed. _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

HI all, On 2020-01-02 12:09 p.m., Hugh Cayless wrote:

Apart from rare exceptions, all you should need to do to get patched versions of packaged software is to build a new image. There is actually nothing I can do on my end to facilitate this process—other than possibly change the base system I’m using. I maintain the Dockerfile that Docker uses to build the image that you run in a container. My understanding of the process is that updates are applied when the image is built. If you want to keep a container hanging around, you could also periodically run apt-get update && apt-get dist-upgrade in your container.

This is what I would recommend.

The attack vectors against your personal machine are not going to be multiplied by doing TEI things in a container that isn’t listening on any ports. You’re probably a bit safer if anything, even running an unpatched system. If a hacker could get access to it, they’re already in your machine, or they’ve compromised something the TEI build process needs. In other words, you were already doomed.

There is one well-known attack vector that we're all vulnerable to, and that's the fact that if any GitHub id of anyone with commit privileges is compromised, then the git repo can be used to launch an attack on any machine that's running a build process based on the repo contents. Normally when you run a build process outside docker, you're running it as your regular user, on a fully-updated machine, so although the results could be bad, it would be unusual if a hacker could get root on your machine that way, except through a zero-day. However, if you're running the build in a docker container which is not updated, it's more likely the hack could get root on that container; and if that's combined with a method of escaping the container, and the container itself is running as root on the host system, then you could be in trouble. And if you don't really understand docker very well (and I don't, even though I use it), then you can end up running things with more privileges than they really merit by accident. I know this does sound a bit paranoid, but I always think we should err on the side of paranoia rather than nonchalance when it comes to security. :-) Cheers, Martin

Note that the above does not apply if you’re running a server—paranoia is fully justified in that case.

Hugh

...

On Jan 2, 2020, at 14:10, Bauman, Syd wrote:

Whether I make it or not, I hope the topic of keeping the Docker containers updated is discussed. My thoughts on this topic follow, in no particular order.

* It is definitely important to keep the OS running in a Docker container up to date with security patches. It may not be as big a problem as Martin worries it is, especially if we are all vigilant in leaving a container running for the minimum amount of time necessary. But it is still important enough that we should have a process for doing it.

* The solution is probably administrative, not technical.

* It is probably unfair to insist that Peter and Hugh be solely responsible for doing this. (That said, if they don't object, I don't either. I would if it were only 1 person -- at least 2 people should know how to do everything that is even semi-important.) Could be a rotating responsibility.

* My suggested administrative idea: Once a month, 1-24 hours *before* the Council meeting, the Docker maintainer or designee should update each container with the latest OS security patches. (Chair should send a reminder 48 hours before the meeting.) Immediately *after* the Council meeting each Council member should download and install the updated container.

* Peter pointed out that doing such an update might break the build within the container. He's right, but that's no reason not to install security patches. It's a reason to fix the build process so it works on a properly updated system. Doing this on meeting day, I figure, gives us a higher chance of noticing a build fail, finding a fix, and promulgating the solution rapidly. _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

-- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre

It’s a bit more complicated than that. The updates are applied when you build the image or do the usual package updates in a container. While it’s possible that security issues could require Peter or me to update the Dockerfiles (the image-building recipes), in general, security is on you. Pace Martin, I don’t see Docker as making your personal TEI build process any more vulnerable to attack than just running it without Docker. If we decide we’re worried about our repos being compromised that way, we’re better off adding virus/vulnerability scanning to our Travis builds.

On Jan 2, 2020, at 18:31, Elisa Beshero-Bondar wrote:

 If I'm following the suggestions here, do they simply amount to making sure that the images we're storing on Docker Hub are updated for security? Or that we as individuals running Docker on our local machines need to be running these updates? I'm imagining what we need is the former, since our local build processes are pulling updated images every time we invoke Docker.

Also, just a reminder that I'm hoping we can move the slated 1/14 meeting to a day when Syd as well as me can be sure to be available.

Elisa

...

On Thu, Jan 2, 2020 at 5:42 PM Martin Holmes wrote: HI all,

On 2020-01-02 12:09 p.m., Hugh Cayless wrote:

...

Apart from rare exceptions, all you should need to do to get patched versions of packaged software is to build a new image. There is actually nothing I can do on my end to facilitate this process—other than possibly change the base system I’m using. I maintain the Dockerfile that Docker uses to build the image that you run in a container. My understanding of the process is that updates are applied when the image is built. If you want to keep a container hanging around, you could also periodically run apt-get update && apt-get dist-upgrade in your container.

This is what I would recommend.

...

The attack vectors against your personal machine are not going to be multiplied by doing TEI things in a container that isn’t listening on any ports. You’re probably a bit safer if anything, even running an unpatched system. If a hacker could get access to it, they’re already in your machine, or they’ve compromised something the TEI build process needs. In other words, you were already doomed.

There is one well-known attack vector that we're all vulnerable to, and that's the fact that if any GitHub id of anyone with commit privileges is compromised, then the git repo can be used to launch an attack on any machine that's running a build process based on the repo contents. Normally when you run a build process outside docker, you're running it as your regular user, on a fully-updated machine, so although the results could be bad, it would be unusual if a hacker could get root on your machine that way, except through a zero-day. However, if you're running the build in a docker container which is not updated, it's more likely the hack could get root on that container; and if that's combined with a method of escaping the container, and the container itself is running as root on the host system, then you could be in trouble. And if you don't really understand docker very well (and I don't, even though I use it), then you can end up running things with more privileges than they really merit by accident.

I know this does sound a bit paranoid, but I always think we should err on the side of paranoia rather than nonchalance when it comes to security. :-)

Cheers, Martin

...

Note that the above does not apply if you’re running a server—paranoia is fully justified in that case.

Hugh

...

On Jan 2, 2020, at 14:10, Bauman, Syd wrote:

Whether I make it or not, I hope the topic of keeping the Docker containers updated is discussed. My thoughts on this topic follow, in no particular order.

* It is definitely important to keep the OS running in a Docker container up to date with security patches. It may not be as big a problem as Martin worries it is, especially if we are all vigilant in leaving a container running for the minimum amount of time necessary. But it is still important enough that we should have a process for doing it.

* The solution is probably administrative, not technical.

* It is probably unfair to insist that Peter and Hugh be solely responsible for doing this. (That said, if they don't object, I don't either. I would if it were only 1 person -- at least 2 people should know how to do everything that is even semi-important.) Could be a rotating responsibility.

* My suggested administrative idea: Once a month, 1-24 hours *before* the Council meeting, the Docker maintainer or designee should update each container with the latest OS security patches. (Chair should send a reminder 48 hours before the meeting.) Immediately *after* the Council meeting each Council member should download and install the updated container.

* Peter pointed out that doing such an update might break the build within the container. He's right, but that's no reason not to install security patches. It's a reason to fix the build process so it works on a properly updated system. Doing this on meeting day, I figure, gives us a higher chance of noticing a build fail, finding a fix, and promulgating the solution rapidly. _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

-- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

-- Elisa Beshero-Bondar, PhD Director, Center for the Digital Text | Associate Professor of English University of Pittsburgh at Greensburg | Humanities Division 150 Finoli Drive Greensburg, PA 15601 USA E-mail: ebb8@pitt.edu Development site: http://newtfire.org _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council