Hi In this case I think we should issue one DLA and tell all the packages that have been updated at the same time. This require some rephrasing compared to a standard DLA but I do not think we should have a lot of them.
This considering that we have fixed all the packages that require re-build. I think it will be difficult to syncronize the fix of several vulnerabilities. This could be done in some specific cases, but generally I think we should accept that we have multiple uploads. Best regards // Ola On Tue, 18 May 2021 at 00:23, Brian May <b...@debian.org> wrote: > Ola Lundqvist <o...@inguza.com> writes: > > > I can also see a note in dla-needed for Thorsten working on automating go > > updates. > > I did a bit of work trying to automate go updates on my system: > > * Identifying what packages need to be updated. > * Downloading said packages. > * Rebuilding. > * Uploading. > > But there is still a lot of manual steps: > > * Confirm that it is OK at add dependencies to dla-needed.txt > * Adding list of dependencies to dla-needed.txt, ensuring no conflicts. > * Reserve DLA for each package uploaded. > * Create DLA email for each package uploaded. > * Add DLA to website. > * Ping ftp-master when the upload fails. > * etc > > And then what could happen (at least in theory) is that now I have > resolved this vulnerability, I start investigating another security > vulnerability that has a similar set of dependencies that require > rebuilding. Uploading these again is not a good outcome. It would be > better to fix all the root packages at once, and then upload the all the > dependencies. > > Maybe we need a way of identifying all the dependencies at triage time, > and somehow(?) manage them better at triage time. Although my gut > feeling is we might be coming to the limits of what we can manage with a > simple text based dla-needed.txt file. > > I am also a bit uneasy with the requirement for a separate DLA for each > and every package that needs to be uploaded. Could create a lot of > noise. Not sure I see any solutions though. > > I think in the future (if we are not already there) we could easily have > a similar situation with rust - which I also believe likes to embed code > also. > -- > Brian May <b...@debian.org> > > -- --- Inguza Technology AB --- MSc in Information Technology ---- | o...@inguza.com o...@debian.org | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
