Re: Debian vs Linux namespaces
On Sat, Mar 23, 2019 at 02:26:08PM +0100, Ond??ej Surý wrote: > > On 23 Mar 2019, at 13:34, Harald Dunkel wrote: > > > > Hi folks, > > > > AFAICS there are several packages that appear to be unaware of / > > do not care about containers, e.g. opensmtpd, bind9, apt-cacher-ng, > > probably everything using pidof or pidofproc from /lib/lsb/init-\ > > functions). > > > > I noticed that containerization and Linux namespaces are not number > > one priority for Debian, but do you think this could be addressed > > for Buster? Its pretty annoying if you try to maintain the Debian host > > system, and a LXC container is affected instead. > > > Hi Harald, Hello mailinglist, > since you are using non-default init system, I would recommend sending > patches along with your bug reports if you want to get niche things fixed. As far as I can see is Harald exploring the amount of niches and a generic solution. > Ondrej > > > > Thanx in advance > > > > Harri > > > > https://bugs.debian.org/888569 > > https://bugs.debian.org/888743 > > https://bugs.debian.org/858837 > > https://bugs.debian.org/924551 > > > Groeten Geert Stappers -- Leven en laten leven
Re: Debian vs Linux namespaces, NMU lsb-base
On Sat, Mar 23, 2019 at 09:49:09PM +0800, Shengjing Zhu wrote: > On Sat, Mar 23, 2019 at 8:41 PM Harald Dunkel wrote: > > > > Hi folks, > > > > AFAICS there are several packages that appear to be unaware of / > > do not care about containers, e.g. opensmtpd, bind9, apt-cacher-ng, > > probably everything using pidof or pidofproc from /lib/lsb/init-\ > > functions). > > > > I noticed that containerization and Linux namespaces are not number > > one priority for Debian, but do you think this could be addressed > > for Buster? Its pretty annoying if you try to maintain the Debian host > > system, and a LXC container is affected instead. > > > > > > Thanx in advance > > > > Harri > > > > https://bugs.debian.org/888569 sysv startup script stumbles over smtpd running in a LXC container > > https://bugs.debian.org/888743 pidofproc returns PIDs in foreign chroots and containers > > https://bugs.debian.org/858837 lsb-base: pidofproc should limit itself to processes in host system if running on an LXC host > > https://bugs.debian.org/924551 startup script affects bind running inside a container > If I read these bugs correctly, all are the same thing and it's the bug in > lsb. > And the straightforward fix mentioned in #888743 and #858837 is to use > `pidof -c` instead of `pidof` in pidofproc function provided by > lsb-base package. > > I think there's no harm for this patch. Quoting manual page `pidof` | -c Only return process PIDs that are running with the same | root directory. This option is ignored for non-root | users, as they will be unable to check the current | root directory of processes they do not own. What would be the harm to the Buster release if lsb-base got NMU with https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=888743;filename=init-functions.diff;msg=37 ? Groeten Geert Stappers -- Leven en laten leven
Re: Is screenshots.debian.net at risk?
On Sat, Mar 23, 2019 at 12:13:37PM +0100, Christoph Haas wrote: > Fellow devs, > > bear with me if the topic of the upcoming european copyright law (aka > §13) has been discussed in other mailing lists. As being responsible for > screenshots.debian.net I honestly am a bit worried about the > implications. As usual??? IANAL. > > Management summary: screenshots.debian.net is a web site that I > developed many many years ago and which is since then providing > user-generated screenshots for applications we manage in Debian. > Everyone can upload screenshots which are then moderated by pabs and me > before being published. We try to take care that screenshots of non-free > packages are not published to avoid copyright issues. And we claim to > publish screenshots under the same license as the software itself is > published. This has been the consensus after discussions on this list > ~10 years ago. Screenshots can be browsed and searched at > https://screenshots.debian.net/ and are also directly linked to from a > lot of web sites like packages.debian.net or packages.ubuntu.com. The > site currently provides 8500 screenshots, has a pretty good uptime and > according to the web server stats gets a good amount of requests. > > I am not only bringing this topic up because there will be a large > amount of rallies today (at least in Germany) and the topic is very hot. > The main reason is that I am working on an updated version of the web > site that will have a revised moderation workflow. pabs suggested that > we should allow all DDs to freely upload screenshots. That is already > implemented in the upcoming version and will be handled by our valued > sso.debian.net client certificates. That of course would mean that DDs > have to take care of copyright problems when uploading stuff. > > A further idea of me is to allow everyone to use SSO providers like > Launchpad, Stackexchange, Google, Amazon and Github. I was considering a > system where users would have to upload a certain number of "good > screenshots" before being allowed to upload freely. I hoped to attract > more people to upload screenshots without the hassle and delay of going > through moderation. pabs and I discussed whether it's worth doing that. > Will there really be so much more user content that it's worth allowing > that? > > Most of us are not lawyers so it may be hard to dig out the ultimate > truth. But I am personally worried because the server is run under my > name and I would not like to get into personal trouble while running a > platform that is providing user-generated content. Because that's what > all the EU law fuss is currently about. > > I would welcome your thoughts on that. Thanks. I'm in a simular situation. I do provide servers with wikis to local user groups. Every person smart enough to register an account upload whatever they please. Do I go implement "filters"?No. Do I go shutdown the various wikis?No. Do I think that "EU article 13" will harm the libre Internet? Yes Groeten Geert Stappers -- Leven en laten leven signature.asc Description: PGP signature
Re: Debian vs Linux namespaces, NMU lsb-base
❦ 24 mars 2019 09:42 +01, Geert Stappers : > What would be the harm to the Buster release > if lsb-base got NMU > with > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=888743;filename=init-functions.diff;msg=37 > ? Wouldn't it break chrooted processes? But mostly, as the whole pattern is broken, it seems to be a low-effort solution. -- Soap and education are not as sudden as a massacre, but they are more deadly in the long run. -- Mark Twain signature.asc Description: PGP signature
Re: Is screenshots.debian.net at risk?
Hi, Quoting Geert Stappers (2019-03-24 09:53:58) > > bear with me if the topic of the upcoming european copyright law (aka §13) > > has been discussed in other mailing lists. As being responsible for > > screenshots.debian.net I honestly am a bit worried about the implications. > > As usual??? IANAL. > > > > Management summary: screenshots.debian.net is a web site that I > > developed many many years ago and which is since then providing > > user-generated screenshots for applications we manage in Debian. > > Everyone can upload screenshots which are then moderated by pabs and me > > before being published. We try to take care that screenshots of non-free > > packages are not published to avoid copyright issues. And we claim to > > publish screenshots under the same license as the software itself is > > published. This has been the consensus after discussions on this list > > ~10 years ago. Screenshots can be browsed and searched at > > https://screenshots.debian.net/ and are also directly linked to from a > > lot of web sites like packages.debian.net or packages.ubuntu.com. The > > site currently provides 8500 screenshots, has a pretty good uptime and > > according to the web server stats gets a good amount of requests. > > > > I am not only bringing this topic up because there will be a large > > amount of rallies today (at least in Germany) and the topic is very hot. > > The main reason is that I am working on an updated version of the web > > site that will have a revised moderation workflow. pabs suggested that > > we should allow all DDs to freely upload screenshots. That is already > > implemented in the upcoming version and will be handled by our valued > > sso.debian.net client certificates. That of course would mean that DDs > > have to take care of copyright problems when uploading stuff. > > > > A further idea of me is to allow everyone to use SSO providers like > > Launchpad, Stackexchange, Google, Amazon and Github. I was considering a > > system where users would have to upload a certain number of "good > > screenshots" before being allowed to upload freely. I hoped to attract > > more people to upload screenshots without the hassle and delay of going > > through moderation. pabs and I discussed whether it's worth doing that. > > Will there really be so much more user content that it's worth allowing > > that? > > > > Most of us are not lawyers so it may be hard to dig out the ultimate > > truth. But I am personally worried because the server is run under my > > name and I would not like to get into personal trouble while running a > > platform that is providing user-generated content. Because that's what > > all the EU law fuss is currently about. > > > > I would welcome your thoughts on that. Thanks. > > I'm in a simular situation. I do provide servers with wikis to local > user groups. Every person smart enough to register an account upload > whatever they please. > > Do I go implement "filters"?No. > > Do I go shutdown the various wikis?No. > > Do I think that "EU article 13" will harm the libre Internet? Yes I am not a lawyer. But from what I read online and from what is written in the latest version of the proposal in Article 2 (6) http://www.europarl.europa.eu/doceo/document/A-8-2018-0245-AM-271-271_EN.pdf It seems that the definition of "online content-sharing service provider" exempts "open source software-developing and- sharing platforms". This might mean that screenshots.debian.net is safe? Probably a better audience for this topic is debian-legal (CC). cheers, josch signature.asc Description: signature
Re: Debian vs Linux namespaces, NMU lsb-base
On Sun, Mar 24, 2019 at 4:42 PM Geert Stappers wrote:
>
> On Sat, Mar 23, 2019 at 09:49:09PM +0800, Shengjing Zhu wrote:
> > On Sat, Mar 23, 2019 at 8:41 PM Harald Dunkel wrote:
> > >
> > > Hi folks,
> > >
> > > AFAICS there are several packages that appear to be unaware of /
> > > do not care about containers, e.g. opensmtpd, bind9, apt-cacher-ng,
> > > probably everything using pidof or pidofproc from /lib/lsb/init-\
> > > functions).
> > >
> > > I noticed that containerization and Linux namespaces are not number
> > > one priority for Debian, but do you think this could be addressed
> > > for Buster? Its pretty annoying if you try to maintain the Debian host
> > > system, and a LXC container is affected instead.
> > >
> > >
> > > Thanx in advance
> > >
> > > Harri
> > >
> > > https://bugs.debian.org/888569
> sysv startup script stumbles over smtpd running in a LXC container
>
> > > https://bugs.debian.org/888743
> pidofproc returns PIDs in foreign chroots and containers
>
> > > https://bugs.debian.org/858837
> lsb-base: pidofproc should limit itself to processes in host system if
> running on an LXC host
>
> > > https://bugs.debian.org/924551
> startup script affects bind running inside a container
>
>
> > If I read these bugs correctly, all are the same thing and it's the bug in
> > lsb.
> > And the straightforward fix mentioned in #888743 and #858837 is to use
> > `pidof -c` instead of `pidof` in pidofproc function provided by
> > lsb-base package.
> >
> > I think there's no harm for this patch.
>
> Quoting manual page `pidof`
>
> | -c Only return process PIDs that are running with the same
> | root directory. This option is ignored for non-root
> | users, as they will be unable to check the current
> | root directory of processes they do not own.
>
>
> What would be the harm to the Buster release
> if lsb-base got NMU
> with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=888743;filename=init-functions.diff;msg=37
> ?
>
Just checked the contents in initscripts-9.49.46-1.el7.x86_64.rpm
```
# Output PIDs of matching processes, found using pidof
__pids_pidof() {
pidof -c -m -o $$ -o $PPID -o %PPID -x "$1" || \
pidof -c -m -o $$ -o $PPID -o %PPID -x "${1##*/}"
}
```
They use -c since 2005,
https://github.com/fedora-sysv/initscripts/commit/2b4f68e
--
Shengjing Zhu
Re: Debian vs Linux namespaces
Hi Ondřej, On 3/23/19 2:26 PM, Ondřej Surý wrote: > Hi Harald, > > since you are using non-default init system, I would recommend sending > patches along with your bug reports if you want to get niche things fixed. > I already did. See the bug reports for lsb and opensmtpd. I stumbled over apt-cacher-ng just recently. IMHO the best fix is to avoid pidof and pidofproc completely and to rely upon the /run/daemonname.pid file as usual. Regards Harri
Re: Bug#888743: Debian vs Linux namespaces, NMU lsb-base
Le dimanche, 24 mars 2019, 09.42:12 h CET Geert Stappers a écrit : > What would be the harm to the Buster release > if lsb-base got NMU > with > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=888743;filename=ini > t-functions.diff;msg=37 ? I have now uploaded src:lsb to experimental with Harald's patch. I'm not comfortable yet to target buster, I must say, nor do I really have time to test this extensively. Le dimanche, 24 mars 2019, 10.16:25 h CET Vincent Bernat a écrit : > Wouldn't it break chrooted processes? But mostly, as the whole pattern > is broken, it seems to be a low-effort solution. Vincent: what scenario did you have in mind? Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#925405: ITP: picotls -- library for TLS 1.3 (RFC 8446)
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor * Package name: picotls Version : 0.0.20190320 Upstream Author : Kazuho Oku * URL : https://github.com/h2o/picotls * License : MIT, CC0 Programming Lang: C Description : library for TLS 1.3 (RFC 8446) Picotls is a compact, opinionated library implementing TLS 1.3. It is useful as an element in other protocol implementations that incorporate TLS 1.3, and it provides two different cryptographic backends (with different licensing implications): - minicrypto (based on cifra and micro-ecc) - OpenSSL (based on OpenSSL) While picotls upstream currently only ships static libraries, I've spoken with Kazuho and he believes picotls is approaching interface stability. The packaging effort here is likely to involve a bit of work with upstream to get it into shape as a shared object with a declared interface. --dkg
Re: Bug#888743: Debian vs Linux namespaces, NMU lsb-base
❦ 24 mars 2019 14:40 +01, Didier 'OdyX' Raboud : >> Wouldn't it break chrooted processes? But mostly, as the whole pattern >> is broken, it seems to be a low-effort solution. > > Vincent: what scenario did you have in mind? For the first part, any daemon chrooting (like HAProxy, lldpd). For the second part, it's just killing by name is fragile. Supervisors or PID files should be used instead. start-stop-daemon makes it easy to get a PID file for a program not able to provide one. -- Make it right before you make it faster. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
