Re: Bits from the Security Team - Debian

This is a discussion on Re: Bits from the Security Team - Debian ; On Sun, 09 Mar 2008, Moritz Muehlenhoff wrote: > If you're opening a ticket for a security problem which is publicly > known, e.g. if it's announced on the project web site, please open a > ticket in the "Security" ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: Bits from the Security Team

  1. Re: Bits from the Security Team

    On Sun, 09 Mar 2008, Moritz Muehlenhoff wrote:
    > If you're opening a ticket for a security problem which is publicly
    > known, e.g. if it's announced on the project web site, please open a
    > ticket in the "Security" queue. These issues will be visible
    > publicly.


    Is there any particular reason why we're duplicating this information
    that should already be present in the bts as bugs with severity
    serious tagged security marked found in a version in stable in RT?

    If there are some change to the BTS needed for the security team to
    track the non-embargoed issues more easily, I'd be glad to make (or at
    the very least discuss) them.

    From where I sit it seems non-ideal for both the security team and
    maintainers (as well as anyone else who is interested) to put this
    information in a system which isn't tied in strongly with the BTS or
    otherwise is unable to track package versioning.


    Don Armstrong

    --
    You could say to the Universe this is not /fair/. And the Universe
    would say: Oh it isn't? Sorry.
    -- Terry Pratchett _Soul Music_ p357

    http://www.donarmstrong.com http://rzlab.ucr.edu

  2. Re: Bits from the Security Team

    On 2008-03-11, Don Armstrong wrote:
    > On Sun, 09 Mar 2008, Moritz Muehlenhoff wrote:
    >> If you're opening a ticket for a security problem which is publicly
    >> known, e.g. if it's announced on the project web site, please open a
    >> ticket in the "Security" queue. These issues will be visible
    >> publicly.

    >
    > Is there any particular reason why we're duplicating this information
    > that should already be present in the bts as bugs with severity
    > serious tagged security marked found in a version in stable in RT?
    >
    > If there are some change to the BTS needed for the security team to
    > track the non-embargoed issues more easily, I'd be glad to make (or at
    > the very least discuss) them.
    >
    > From where I sit it seems non-ideal for both the security team and
    > maintainers (as well as anyone else who is interested) to put this
    > information in a system which isn't tied in strongly with the BTS or
    > otherwise is unable to track package versioning.


    This doesn't intend to duplicate information from the BTS. The RT
    queues even contain direct links to the BTS. RT is used to distribute
    work among the members of the security team and to keep pending
    issues more organized.
    RT mostly replaces sending to mail to team@security.debian.org if a
    maintainer wants to assist in preparing a security update. Mail doesn't
    scale very well, so we've had occasional smaller issues being lost in
    the noise.

    Cheers,
    Moritz


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Re: Bits from the Security Team

    On Fri, 14 Mar 2008, Moritz Muehlenhoff wrote:
    > This doesn't intend to duplicate information from the BTS. The RT
    > queues even contain direct links to the BTS. RT is used to
    > distribute work among the members of the security team and to keep
    > pending issues more organized.


    You could actually do all of that pretty easily using usertags or
    similar, but it's your process. The main reason that I wanted to
    clarify this is because the instructions sound like RT should be used
    in lieu of the BTS, which isn't such a great idea.

    The secondary reason is that it's very useful to see in a single
    location the exact status of non-embargoed security bugs; using RT
    means that someone who is interested has to find the RT bug which
    corresponds to the package they're interested in and then check the
    corresponding BTS bug (though I suppose this could be mitigated by
    adding a reverse link to the RT bug from the bts using the forwarded
    field or similar.)

    > RT mostly replaces sending to mail to team@security.debian.org if a
    > maintainer wants to assist in preparing a security update. Mail doesn't
    > scale very well, so we've had occasional smaller issues being lost in
    > the noise.


    I agree that some method of tracking what the stable security team is
    working on is a good idea; e-mail definetly doesn't scale.


    Don Armstrong

    --
    This can't be happening to me. I've got tenure.
    -- James Hynes _Publish and Perish_

    http://www.donarmstrong.com http://rzlab.ucr.edu


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: Bits from the Security Team

    Hi Don,
    * Don Armstrong [2008-03-14 20:42]:
    > On Fri, 14 Mar 2008, Moritz Muehlenhoff wrote:

    [...]
    > The secondary reason is that it's very useful to see in a single
    > location the exact status of non-embargoed security bugs; using RT
    > means that someone who is interested has to find the RT bug which
    > corresponds to the package they're interested in and then check the
    > corresponding BTS bug (though I suppose this could be mitigated by
    > adding a reverse link to the RT bug from the bts using the forwarded
    > field or similar.)


    That's what the security tracker is for.
    http://security-tracker.debian.net/tracker/
    http://security-tracker.debian.net/tracker/

    Kind regards
    Nico
    --
    Nico Golde - http://www.ngolde.de - nion@jabber.ccc.de - GPG: 0x73647CFF
    For security reasons, all text in this mail is double-rot13 encrypted.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH2uCxHYflSXNkfP8RAtPVAKC5wJKjY0nkh5TzodxJjP jRFNmz1ACfW+1f
    cE3p8Ptg1bda1k3ChKUgGLc=
    =w7Av
    -----END PGP SIGNATURE-----


+ Reply to Thread