Processed: fixed 932704 in 4.5.0.0
Processing commands for cont...@bugs.debian.org:
> fixed 932704 4.5.0.0
Bug #932704 {Done: David Steele } [debian-policy]
debian-policy: Don't force sysvinit compatibility if e.g. alternate init
required
Marked as fixed in versions debian-policy/4.5.0.0.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
932704: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932704
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#932704: marked as done (debian-policy: Don't force sysvinit compatibility if e.g. alternate init required)
Your message dated Tue, 21 Jan 2020 16:26:53 -0500 with message-id and subject line Issue resolved in Policy has caused the Debian Bug report #932704, regarding debian-policy: Don't force sysvinit compatibility if e.g. alternate init required to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 932704: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932704 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: debian-policy Version: 4.4.0.1 Severity: normal In section 9.11 (The Operating System/Alternate init systems), it is stated that "...any package integrating with other init systems must also be backwards-compatible with sysvinit by providing a SysV-style init script...". There is a single exception for the alternate init system implementation itself. There are other exception conditions that we may want to consider here. For instance, if a package has an explicit dependency on a particular "alternate" init system, to, say, access the systemd D-Bus interface, there is likely little value in providing sysv init scripts. I suggest that something like the following line be added to the end of the second paragraph in that section: "Also, SysV-style init scripts may be omitted for packages which have an explicit dependency on an alternate init system." -- AE0D BF5A 92A5 ADE4 9481 BA6F 8A31 71EF 3661 50CE --- End Message --- --- Begin Message --- The problem identified in the submission is resolved in Debian Policy version 4.5.0.--- End Message ---
Bug#940144: developers-reference: document self-service givebacks in wanna-build section
On Tue, Jan 21, 2020 at 09:20:54PM +0100, Philipp Kern wrote: > That being said, tracker, nm and contributors already moved to request > client certificates on the main host. In their case it didn't really change anything, since they had the client certificate bit in their section. > And yes, the correct approach would be something like OAuth2. Or use > client certificates with some sort of CLI. :/ Then get the sso.d.o team to do that, in a sane way. We are still waiting for an interface to register guest accounts, that has been ready for more than a year now but apparently has trouble being deployed. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#940144: developers-reference: document self-service givebacks in wanna-build section
On 1/21/2020 4:50 PM, Sam Hartman wrote: >> "Philipp" == Philipp Kern writes: > > Philipp> I'm told it was broken by the upgrade of Apache - apparently it > can no > Philipp> longer do per path client certificate authentication. There is a > Philipp> pending RT ticket from DSA to fix that but I don't think there is > Philipp> anything I can do at the moment - except turn on SSO for the > whole > Philipp> vhost. Maybe that could even be a workaround for now and we could > Philipp> check if someone is annoyed by that. :) > > TLS dropped the facilities necessary to do that. > Ultimately you'll need a vhost for stuff that requires client certs and > other vhosts that do not. > The user experience of having a site request client certs when you don't > have one to give is really bad in some browsers. > > Client certs really kind of are the unloved step child of web > authentication. Yeah, so Julien helpfully just created auth.buildd.debian.org (thanks for that!). I'm going to spend some time on that tomorrow. That being said, tracker, nm and contributors already moved to request client certificates on the main host. I find the UI problematic when you actually have a cert, as it will show a problem. In enterprise environments you can push a policy to not ask about which certificate to use but for privacy reasons it is still explicit in the normal case. And yes, the correct approach would be something like OAuth2. Or use client certificates with some sort of CLI. :/ Kind regards Philipp Kern
Bug#940144: developers-reference: document self-service givebacks in wanna-build section
> "Philipp" == Philipp Kern writes: Philipp> I'm told it was broken by the upgrade of Apache - apparently it can no Philipp> longer do per path client certificate authentication. There is a Philipp> pending RT ticket from DSA to fix that but I don't think there is Philipp> anything I can do at the moment - except turn on SSO for the whole Philipp> vhost. Maybe that could even be a workaround for now and we could Philipp> check if someone is annoyed by that. :) TLS dropped the facilities necessary to do that. Ultimately you'll need a vhost for stuff that requires client certs and other vhosts that do not. The user experience of having a site request client certs when you don't have one to give is really bad in some browsers. Client certs really kind of are the unloved step child of web authentication.
