Joey Hess wrote:> Moritz Muehlenhoff wrote: > > It''s now in the dtsa script. If in doubt we should use a relaxed defition > > of "remote" to prevent giving a warm fuzzy false feeling of security. > > So if I run dtsa -u 1 it doesn''t seem to do anything. Shouldn''t I get a > filled out template or some sort of output?dtsa -u is only used for updating DTSA that have already been published, i.e. for cases where DTSA-X-2 would become necessary. This isn''t implemented yet, I''m currently working on it. To generate the template right now please use "dtsa -a 1". To bring the rest of the rest in the loop; I''m thinking of the following work flow: 1. Someone is working on a vulnerability in package foo. He checks the highest currently unused DTSA number and commits an initial .adv file into SVN. (can be automated with a little shell script that extracts the highest number and performs the checkin) This is the equivalent of the "claimed" markers for data/CAN/list. 2. Once he''s written his advisory template, tested the uploaded fix and everything is in shape for release he uses dtsa.py -a. All information is automatically included in data/DTSA/list. HTML output is generated and rsynched to the website (not implemented yet) and the textual form can be send to -announce with sndadvisory.>From now on a DTSA is kept as "published".3. If it is "published" an update can be issued with dtsa.py -u, which automatically updates data/DTSA/list and increases the DTSA code by a minor number. HTML and textual representation are again made public. Cheers, Moritz
Anthony DeRobertis wrote:> Moritz Muehlenhoff wrote: > > > - The install recommendation uses apt-get install foo. So we''d need to > > specify a list of all binary names here to properly install the update. > > Shouldn''t we just recommend dist-upgrade instead? (If people use the > > testing security apt repo they don''t have to cherry pick fixes) > > apt-get dist-upgrade might very well pull in a lot of stuff which isn''t > related to the update (considering testing changes nightly, this is > fairly likely).Yes. On the other hand, it''s hard to give apt-get install commands that work in all cases. For example, a DTSA of mozilla will include several mozilla-* packages, some of which might include some security fixes. But a user might not have them all installed so recommending an apt-get install mozilla-* is not a good idea. I guess people running testing should be comfortable with an apt-get upgrade upgrading lots of stuff, so that seems like the best solution to me. Especially since security fixes tend to get into testing via normal means on a daily basis anyway, so users really need to apt-get upgrade anyway. One thing I have been trying to figure out is whether we should issue some kind of advisory/summary for those, or just ignore them, or what. -- see shy jo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050828/f58a03bb/attachment.pgp
Moritz Muehlenhoff wrote:> - The install recommendation uses apt-get install foo. So we''d need to > specify a list of all binary names here to properly install the update. > Shouldn''t we just recommend dist-upgrade instead? (If people use the > testing security apt repo they don''t have to cherry pick fixes)apt-get dist-upgrade might very well pull in a lot of stuff which isn''t related to the update (considering testing changes nightly, this is fairly likely).
Joey Hess wrote:> > - Problem-Type should be renamed to "Problem Scope" or "Vulnerability > > Scope". OTOH it might be dropped completely, it''s hard to decide > > in several cases (e.g. when s/o processes some file that triggers > > a vulnerability the attack vector may very well be remote, if this > > s/o receives the file by mail) and may give a false sense of security. > > I only included that since it''s in DSAs. OTOH, I think it''s easy to make > the judgement call about whether the vulnerability is a remote hole in a > standard setups or not.It''s now in the dtsa script. If in doubt we should use a relaxed defition of "remote" to prevent giving a warm fuzzy false feeling of security.> > - The install recommendation uses apt-get install foo. So we''d need to > > specify a list of all binary names here to properly install the update. > > Shouldn''t we just recommend dist-upgrade instead? (If people use the > > testing security apt repo they don''t have to cherry pick fixes) > > I''ve been editing that to use apt-get upgrade for DTSAs that include > more than one binary package. But IMHO dist-upgrade should be unnecessary, > we won''t be adding/removing packages. Hopefully.^^^^^^^^^ :-) Cheers, Moritz
Joey Hess wrote:> Moritz Muehlenhoff wrote: > > dtsa -u is only used for updating DTSA that have already been published, > > i.e. for cases where DTSA-X-2 would become necessary. This isn''t implemented > > yet, I''m currently working on it. > > To generate the template right now please use "dtsa -a 1". > > Ok, calling that "announce" is misleading, since it does not really post > the announcement. Also, dtsa doesn''t right-align the url and author at > the top of the template,Fixed.> and it should add new items to the top of the > list file, not to the end.Does one of the other scripts depend on this behaviour? Adding it to the front is rather ugly inplace editing, while adding it the end is a plain append operation. Or does anyone know a pythonesque workaround?> Oh and you put the wrong date in the list, in > case you didn''t notice. :-)That was used as a workaround, because the descriptional date in the advisory differs from the one in data/DTSA/list. Let''s add the date in ISO format (i.e 2005-08-11) into the .adv file, then I''ll transform it into the proper formats. It the date entry in data/DTSA/list used besides statistical evaluation?> > To bring the rest of the rest in the loop; I''m thinking of the following > > work flow: > > > > 1. Someone is working on a vulnerability in package foo. He checks the > > highest currently unused DTSA number and commits an initial .adv file > > into SVN. (can be automated with a little shell script that extracts the > > highest number and performs the checkin) > > This is the equivalent of the "claimed" markers for data/CAN/list. > > This is ok as long as we don''t mind possibly announcing DTSA''s in > non-numerical order as later ones get finished before earlier ones.I guess that can''t be avoided, as some advisories will require more time than others. Security team works this way as well. Cheers, Moritz
Joey Hess wrote:> > Does one of the other scripts depend on this behaviour? Adding it to the > > front is rather ugly inplace editing, while adding it the end is a plain > > append operation. Or does anyone know a pythonesque workaround? > > No, nothing depends on ordering, it''s just what we expect.Ok, I''ll fix this tomorrow.> > That was used as a workaround, because the descriptional date in the > > advisory differs from the one in data/DTSA/list. Let''s add the date > > in ISO format (i.e 2005-08-11) into the .adv file, then I''ll transform > > it into the proper formats. It the date entry in data/DTSA/list used > > besides statistical evaluation? > > No, we could just as well remove that date field. Although I might use > the one in DSA/list if I ever fix the page to have links to DSAs, since > you have to know the year of a DSA to link to it on the Debian web site.Ok, then let''s remove it from data/DTSA/list for the sake of KISS. I''ll adapt the dtsa script.> > I guess that can''t be avoided, as some advisories will require more time > > than others. Security team works this way as well. > > There are ways to avoid it, but I don''t know if they''re worth it.We could add them to SVM w/o a number and only assign the number at the stage, where the final version is published. I don''t have any preference here.> OTOH, I cannot remember the security team ever sending DSAs out of order.They did, for the last time at the time after the defunct state of security support, when several updates were prepared by several persons. They keep the initial data, so it''s a bit hard to notice in retrospect. Moritz
Moritz Muehlenhoff wrote:> Hi, > while adapting dtsa.py to the new DTSA format template from Joey > I stumbled upon some things I''d like to discuss/change: > > - Problem-Type should be renamed to "Problem Scope" or "Vulnerability > Scope". OTOH it might be dropped completely, it''s hard to decide > in several cases (e.g. when s/o processes some file that triggers > a vulnerability the attack vector may very well be remote, if this > s/o receives the file by mail) and may give a false sense of security.I only included that since it''s in DSAs. OTOH, I think it''s easy to make the judgement call about whether the vulnerability is a remote hole in a standard setups or not.> - The upgrade recommendation shouldn''t differentiate between different > severity formulations. Everything issues as a DTSA should be important > enough (above reasons apply as well)Agreed, that was a silly think for me to put in.> - Obviously: does not track..: stable (Sarge instead of Woody), oldstable > should be mentioned as wellYes.> - The install recommendation uses apt-get install foo. So we''d need to > specify a list of all binary names here to properly install the update. > Shouldn''t we just recommend dist-upgrade instead? (If people use the > testing security apt repo they don''t have to cherry pick fixes)I''ve been editing that to use apt-get upgrade for DTSAs that include more than one binary package. But IMHO dist-upgrade should be unnecessary, we won''t be adding/removing packages. Hopefully. -- see shy jo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050828/45b408e7/attachment.pgp
also sprach Anthony DeRobertis <anthony@derobert.net> [2005.08.28.1914 +0200]:> > - The install recommendation uses apt-get install foo. So we''d need to > > specify a list of all binary names here to properly install the update. > > Shouldn''t we just recommend dist-upgrade instead? (If people use the > > testing security apt repo they don''t have to cherry pick fixes) > > apt-get dist-upgrade might very well pull in a lot of stuff which isn''t > related to the update (considering testing changes nightly, this is > fairly likely).apt-get install -t testing would install all required packages from testing too, including new dependencies. -- .''''`. martin f. krafft <madduck@debian.org> : :'' : proud Debian developer and author: http://debiansystem.info `. `''` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! i feel like i''m diagonally parked in a parallel universe. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature (GPG/PGP) Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050828/16a208d2/attachment.pgp
Moritz Muehlenhoff wrote:> It''s now in the dtsa script. If in doubt we should use a relaxed defition > of "remote" to prevent giving a warm fuzzy false feeling of security.So if I run dtsa -u 1 it doesn''t seem to do anything. Shouldn''t I get a filled out template or some sort of output? -- see shy jo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050828/4cb58f2b/attachment.pgp
Moritz Muehlenhoff wrote:> dtsa -u is only used for updating DTSA that have already been published, > i.e. for cases where DTSA-X-2 would become necessary. This isn''t implemented > yet, I''m currently working on it. > To generate the template right now please use "dtsa -a 1".Ok, calling that "announce" is misleading, since it does not really post the announcement. Also, dtsa doesn''t right-align the url and author at the top of the template, and it should add new items to the top of the list file, not to the end. Oh and you put the wrong date in the list, in case you didn''t notice. :-)> To bring the rest of the rest in the loop; I''m thinking of the following > work flow: > > 1. Someone is working on a vulnerability in package foo. He checks the > highest currently unused DTSA number and commits an initial .adv file > into SVN. (can be automated with a little shell script that extracts the > highest number and performs the checkin) > This is the equivalent of the "claimed" markers for data/CAN/list.This is ok as long as we don''t mind possibly announcing DTSA''s in non-numerical order as later ones get finished before earlier ones. -- see shy jo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050828/fcfd5e7c/attachment.pgp
Moritz Muehlenhoff wrote:> Does one of the other scripts depend on this behaviour? Adding it to the > front is rather ugly inplace editing, while adding it the end is a plain > append operation. Or does anyone know a pythonesque workaround?No, nothing depends on ordering, it''s just what we expect. Buffer file, write new, write buffer. :-)> That was used as a workaround, because the descriptional date in the > advisory differs from the one in data/DTSA/list. Let''s add the date > in ISO format (i.e 2005-08-11) into the .adv file, then I''ll transform > it into the proper formats. It the date entry in data/DTSA/list used > besides statistical evaluation?No, we could just as well remove that date field. Although I might use the one in DSA/list if I ever fix the page to have links to DSAs, since you have to know the year of a DSA to link to it on the Debian web site.> I guess that can''t be avoided, as some advisories will require more time > than others. Security team works this way as well.There are ways to avoid it, but I don''t know if they''re worth it. OTOH, I cannot remember the security team ever sending DSAs out of order. -- see shy jo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050828/67d1cfbf/attachment.pgp
Hi,
while adapting dtsa.py to the new DTSA format template from Joey
I stumbled upon some things I''d like to discuss/change:
- Problem-Type should be renamed to "Problem Scope" or
"Vulnerability
Scope". OTOH it might be dropped completely, it''s hard to decide
in several cases (e.g. when s/o processes some file that triggers
a vulnerability the attack vector may very well be remote, if this
s/o receives the file by mail) and may give a false sense of security.
- The upgrade recommendation shouldn''t differentiate between different
severity formulations. Everything issues as a DTSA should be important
enough (above reasons apply as well)
- Obviously: does not track..: stable (Sarge instead of Woody), oldstable
should be mentioned as well
- The install recommendation uses apt-get install foo. So we''d need to
specify a list of all binary names here to properly install the update.
Shouldn''t we just recommend dist-upgrade instead? (If people use the
testing security apt repo they don''t have to cherry pick fixes)
Cheers,
Moritz