Bug#817286: Simplify testing access for packages on security-master
On Thu, Nov 30, 2017 at 11:59:26AM +0100, Raphael Hertzog wrote: > Hello Moritz, > > On Wed, 09 Mar 2016, Moritz Muehlenhoff wrote: > > (This is a first high level view, the exact requirements can be hashed > > out later.) > > It would be good to go a bit into more details now. > > > It would be great to have a simple (single command) method to simplify > > testing security updates. Right now these need to copied manually to > > the respective test hosts. If it's not available via apt, this is a > > problem for many people since they are unable to find out which binary > > packages are installed and how to update them via dpkg. > > > > There should be a method to allow > > - publishing a public security issue to a permanent staging repository > > ala jessie-security-staging, which people can keep in their apt source > > > > - publishing an non-public security issue to a protected apt > > repository to simplify testing for members of the security team > > Are you only asking for two repositories that can be targetted with > dput? Or are you asking for more? No, this is unrelated to upload queues. This needs a script/ dak command which allows to copy an existing update to the staging repository (which people can add to their apt sources). There's multiple use cases for public vulnerabilities: - For a public vulnerability there's a delay between the initial upload to security-master and until all builds have arrived, advisory text written etc. During that period the packages would be available for pre-release testing (for interested users). - For some packages we rely on external testers since a practical test is too difficult to replicate. Right now we must copy those packages manually to people.debian.org, having such a public repo would make this also much simpler for people to test. So having a command like "dak-publish-staging emacs25" would simplify this a lot. Packages should be pruned from the staging repo when packages get installed via "dak new-security-install". In addition we sometimes also need to pass selected not-yet-public security fixes to testers (and also to simply testing ourselves). For that it would be nice to selectively push into a separate repository which is only accessible with a key. But that is more icing on the cake, the important bit is the implementaton of the public staging repo. Let me know if you have more questions or further details are necessary. Cheers, Moritz
Bug#817286: Simplify testing access for packages on security-master
On Thu, 30 Nov 2017, Salvatore Bonaccorso wrote: > > Are you only asking for two repositories that can be targetted with > > dput? Or are you asking for more? > > No not really a second dput upload. We were thinking of: once a > package is in the embargoed policy queue and the issues for the > respective packages are public, via a dak command(?) publish/stage > them in say a "$odename-security-proposed-updates" (or in Moritz's > words $codename-security-staging) suites which can be configured by > users and which has these selectively choosen packages apt > installable. Ok, understood. That works well for packages that have an embargo and that are uploaded during the embargo. How do you see that for the others? The same command should also work on the unembargoed policy queue (I assume there's a policy queue here as well)? And for the LTS use-case, we should be able to upload directly to that staging repository as well. And moving it to the final repository should be doable with another upload (or a dcut command). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#817286: Simplify testing access for packages on security-master
Hi Raphael, On Thu, Nov 30, 2017 at 11:59:26AM +0100, Raphael Hertzog wrote: > Hello Moritz, > > On Wed, 09 Mar 2016, Moritz Muehlenhoff wrote: > > (This is a first high level view, the exact requirements can be hashed > > out later.) > > It would be good to go a bit into more details now. > > > It would be great to have a simple (single command) method to simplify > > testing security updates. Right now these need to copied manually to > > the respective test hosts. If it's not available via apt, this is a > > problem for many people since they are unable to find out which binary > > packages are installed and how to update them via dpkg. > > > > There should be a method to allow > > - publishing a public security issue to a permanent staging repository > > ala jessie-security-staging, which people can keep in their apt source > > > > - publishing an non-public security issue to a protected apt > > repository to simplify testing for members of the security team > > Are you only asking for two repositories that can be targetted with > dput? Or are you asking for more? No not really a second dput upload. We were thinking of: once a package is in the embargoed policy queue and the issues for the respective packages are public, via a dak command(?) publish/stage them in say a "$odename-security-proposed-updates" (or in Moritz's words $codename-security-staging) suites which can be configured by users and which has these selectively choosen packages apt installable. > Do you have any idea of how the authentication would work for the > non-public repository? This has yet to be though of how this can be done. This just as quick followup, sure Moritz will comment as well. Regards, Salvatore
Bug#817286: Simplify testing access for packages on security-master
Hello Moritz, On Wed, 09 Mar 2016, Moritz Muehlenhoff wrote: > (This is a first high level view, the exact requirements can be hashed > out later.) It would be good to go a bit into more details now. > It would be great to have a simple (single command) method to simplify > testing security updates. Right now these need to copied manually to > the respective test hosts. If it's not available via apt, this is a > problem for many people since they are unable to find out which binary > packages are installed and how to update them via dpkg. > > There should be a method to allow > - publishing a public security issue to a permanent staging repository > ala jessie-security-staging, which people can keep in their apt source > > - publishing an non-public security issue to a protected apt > repository to simplify testing for members of the security team Are you only asking for two repositories that can be targetted with dput? Or are you asking for more? Do you have any idea of how the authentication would work for the non-public repository? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#817286: Simplify testing access for packages on security-master
On Wed, Mar 09, 2016 at 07:41:57PM +0100, Moritz Muehlenhoff wrote: > Package: ftp.debian.org > Severity: wishlist > > This was discussed at one of the past security team meetings, but > there was never a bug for that: > > (This is a first high level view, the exact requirements can be hashed > out later.) > > It would be great to have a simple (single command) method to simplify > testing security updates. Right now these need to copied manually to > the respective test hosts. If it's not available via apt, this is a > problem for many people since they are unable to find out which binary > packages are installed and how to update them via dpkg. > > There should be a method to allow > - publishing a public security issue to a permanent staging repository > ala jessie-security-staging, which people can keep in their apt source > > - publishing an non-public security issue to a protected apt > repository to simplify testing for members of the security team I am not very familiar with the internals of DAK, but to me this should be setup similarly to how the stable-proposed-updates currently are setup. Couldn't there be a suite before "security" in dak? For those, like me, who are struggling to keep in RAM all those suites, I've updated the flow diagram that madduck made a while back, so now it looks like this: https://wiki.debian.org/DebianReleases#Workflow There's probably a bunch of mistakes there, it's in the wrong place (moinmoin wiki that doesn't keep revisions instead of real docs somewhere) but i had to stop shaving yaks at *some* point. A. -- It is a miracle that curiosity survives formal education - Albert Einstein signature.asc Description: Digital signature
Bug#817286: Simplify testing access for packages on security-master
Package: ftp.debian.org Severity: wishlist This was discussed at one of the past security team meetings, but there was never a bug for that: (This is a first high level view, the exact requirements can be hashed out later.) It would be great to have a simple (single command) method to simplify testing security updates. Right now these need to copied manually to the respective test hosts. If it's not available via apt, this is a problem for many people since they are unable to find out which binary packages are installed and how to update them via dpkg. There should be a method to allow - publishing a public security issue to a permanent staging repository ala jessie-security-staging, which people can keep in their apt source - publishing an non-public security issue to a protected apt repository to simplify testing for members of the security team Cheers, Moritz
