Hi, On Thu, Jul 18, 2024 at 5:15 AM Andres Salomon <dilin...@queued.net> wrote: > > On 7/4/24 03:01, Jérémy Lal wrote: > > > > > > Le jeu. 4 juil. 2024 à 06:33, Salvatore Bonaccorso <car...@debian.org > > <mailto:car...@debian.org>> a écrit : > > > > Hi, > > > > On Wed, Jul 03, 2024 at 11:36:46PM +0200, Jérémy Lal wrote: > > > Le mer. 3 juil. 2024 à 23:04, Andres Salomon <dilin...@queued.net > > <mailto:dilin...@queued.net>> a écrit : > [...] > > > > While we wait for this, is there any reason to keep the existing > > > > 18.20.3+dfsg-1~deb12u1 upload in the embargoed security queue? > > Security > > > > packages are actively building against it, which is a bit of a > > problem > > > > for reproducibility. Someone actually asked me about oddities > > in the > > > > chromium package that was originally built for > > bookworm-security, and > > > > now sits in the 12.6 point release. It turns out that it built > > against > > > > the embargoed nodejs, but since that nodejs package was never > > released, > > > > they can't use it to reproduce the chromium in 12.6. > > > > > > > > If there's a new nodejs bookworm-security package being > > uploaded at some > > > > point and the currently embargoed nodejs package will never be > > released, > > > > perhaps we should REJECT it now? > > > > > > > > > > Sorry, probably me being overbooked here. > > > I was supposed to check the regressions against it, and been on > > another job > > > since then. > > > > Aron is taking care of the DSA, so I do not want to interfer here with > > his planning, but sharing an idea: There will be an upcoming release > > for nodejs on Monday, 8th (actually was planned for today): > > https://nodejs.org/en/blog/vulnerability/july-2024-security-releases > > <https://nodejs.org/en/blog/vulnerability/july-2024-security-releases> > > > > Do you think you will be less overbooked, can review the regression > > report and with Aron's help work on fixing the new CVEs for mondays > > release and we base the update upon that? > > > > > > Yes, I'll have more time next week, so it's doable. > > > > > > Again, I do not mean to interfer here with Aron was thinking about > > releasing the packages. > > > > I just uploaded another chromium security update, and it's once again > building against a version of nodejs that hasn't been released to the > public. > > I encourage Jérémy to take as long as he needs to in ensuring that the > nodejs upload (whether 18.19.x or 18.20.x) is properly tested and to his > preferred standard of quality rather than attempting to squeeze it in > based on my nagging him. And I also want to thank him for his continued > handling of nodejs. > > However, in the meantime while we wait for the nodejs upload to be ready > for release, I'd encourage the security team to: > > a) REJECT the upload until Jérémy has time to ensure it's ready for > release (unless Jérémy objects), and > > b) come up with a policy about how long embargoed security uploads that > aren't quite ready for release can sit in the queue (and get used by > other uploads for building) before removing them. >
I agree that we can reject the upload for the moment to help chromium updates, until we are in a more suitable time (autopkgtest resolved) we can re-upload them. I'm going to this shortly. Thanks
