Secure testing team - Mar 2006 - what else needs a DTSA right now?

Joey Hess wrote:
> > > Can anyone suggest any more good candidates for DTSAs in the list
of
> > > unfixed holes in testing? I''ve been trying to cover all
the remote
> > > exploits and bad local exploits and aside from updating the
kernel and
> > 
> > I want to have a deeper look at this. Horms has some stuff pending
> > he hasn''t had the time to backport yet and some CVE
assignments are
> > pending, but preparing updated recent 2.6.8 and 2.4.27 packages
> > for etch seems like a good idea (as they are security/major fix only
> > anyway), until linux-2.6 has made it into testing.
> 
> The big problem with this is that it cannot be autobuilt since etch
> still has all the different kernel source packages.
Yes, but plenty of porters in debian-kernel were building the kernels
Horms prepared for Sarge, so they might be willing to do the same for
Etch as well.
 
> One nice opportunity we have though, is to let developers do uploads and
> testing, so I do encourage that.
We should create a boilerplate text for direct inclusion in bug reports,
so this won''t be missed.
 
> > BTW2, in cases where the maintainer has uploaded fixed packages,
> > we should add them to the DTSA: to prevent ill-feelings/mischief and
> > also as a direct indicator who''s to blame if something goes
wrong ;-)
> 
> Heh, sure, any idea where to list them?
No concrete idea, above the "Upgrade Instructions", maybe?
 
> > >  - zlib: too young in unstable, would rather not add new
upstreams of
> > >    core libs to the repo until we know what can go wrong
> > 
> > The DSAs contain patches against 1.2.2, so they''d be good
alternatives.
> > 
> > OTOH, I can''t remember any major code changes, when I
reviewed the changes
> > while preparing the fix for UCS; it was mostly portability fixes and
> > changes for contrib compression algos.
> 
> Would you like to do a DTSA for it?
Generally, yes. But I have to prepare some work for my thesis colloquium on
Thursday, so if anyone has free time before that, go ahead.

Cheers,
        Moritz

Joey Hess wrote:
> Can anyone suggest any more good candidates for DTSAs in the list of
> unfixed holes in testing? I''ve been trying to cover all the remote
> exploits and bad local exploits and aside from updating the kernel and
I want to have a deeper look at this. Horms has some stuff pending
he hasn''t had the time to backport yet and some CVE assignments are
pending, but preparing updated recent 2.6.8 and 2.4.27 packages
for etch seems like a good idea (as they are security/major fix only
anyway), until linux-2.6 has made it into testing.
> I also looked at these:
> 
>  - drupal: should get into testing soon on its own
The maintainer didn''t add bug closers to his upload and therefore
the RC security bugs prevented testing migration for the last ten
days :-/
>  - bluez-utils: needs bluez-libs updated too, which could be tricky
>  - pdns: too young in unstable
BTW, To what extent did you test the packages, you''ve prepared so far?
These seem to be cases, where it would be best if the maintainer would
prepare fixed packages, as testing is rather difficult (requiring
Bluetooth gadgets or the knowledge to setup a relatively obscure DNS
server).

BTW2, in cases where the maintainer has uploaded fixed packages,
we should add them to the DTSA: to prevent ill-feelings/mischief and
also as a direct indicator who''s to blame if something goes wrong ;-)
>  - zlib: too young in unstable, would rather not add new upstreams of
>    core libs to the repo until we know what can go wrong
The DSAs contain patches against 1.2.2, so they''d be good alternatives.

OTOH, I can''t remember any major code changes, when I reviewed the
changes
while preparing the fix for UCS; it was mostly portability fixes and
changes for contrib compression algos.

Cheers,
        Moritz

Moritz Muehlenhoff wrote:
> Joey Hess wrote:
> > Can anyone suggest any more good candidates for DTSAs in the list of
> > unfixed holes in testing? I''ve been trying to cover all the
remote
> > exploits and bad local exploits and aside from updating the kernel and
> 
> I want to have a deeper look at this. Horms has some stuff pending
> he hasn''t had the time to backport yet and some CVE assignments
are
> pending, but preparing updated recent 2.6.8 and 2.4.27 packages
> for etch seems like a good idea (as they are security/major fix only
> anyway), until linux-2.6 has made it into testing.
The big problem with this is that it cannot be autobuilt since etch
still has all the different kernel source packages.
> > I also looked at these:
> > 
> >  - drupal: should get into testing soon on its own
> 
> The maintainer didn''t add bug closers to his upload and therefore
> the RC security bugs prevented testing migration for the last ten
> days :-/
Yes, just closed it though. I''ll also hint it as urgent since
it''s
already had sufficient testing.
> >  - bluez-utils: needs bluez-libs updated too, which could be tricky
> >  - pdns: too young in unstable
> 
> BTW, To what extent did you test the packages, you''ve prepared so
far?
> These seem to be cases, where it would be best if the maintainer would
> prepare fixed packages, as testing is rather difficult (requiring
> Bluetooth gadgets or the knowledge to setup a relatively obscure DNS
> server).
My testing has varied. I have at least tested that each package
installs, but if I don''t use the package it is hard to do any kind of
complete testing. 

In cases like these where I am only rebuilding a package from unstable
on testing with no changes, the opportuities for breakage should not be
much more than those occuring during normal autobuilding though.

One nice opportunity we have though, is to let developers do uploads and
testing, so I do encourage that.
> BTW2, in cases where the maintainer has uploaded fixed packages,
> we should add them to the DTSA: to prevent ill-feelings/mischief and
> also as a direct indicator who''s to blame if something goes wrong
;-)
Heh, sure, any idea where to list them?
> >  - zlib: too young in unstable, would rather not add new upstreams of
> >    core libs to the repo until we know what can go wrong
> 
> The DSAs contain patches against 1.2.2, so they''d be good
alternatives.
> 
> OTOH, I can''t remember any major code changes, when I reviewed the
changes
> while preparing the fix for UCS; it was mostly portability fixes and
> changes for contrib compression algos.
Would you like to do a DTSA for it?

-- 
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/20050830/f3b8c264/attachment.pgp

On Wed, Aug 31, 2005 at 09:49:06AM -0400, Joey Hess
wrote:
> Steve Langasek wrote:
> > There''s zlib1g/1:1.2.2-4.sarge.2 in t-p-u on spohr for 10 of
11
> > architectures; getting the s390 binaries accepted requires ftp-master
> > intervention because a race condition was hit with the upload, but
once
> > that''s done, we can push the same DSA binaries directly into
testing...
> Hmm, if pushing DSA bins to testing is an option,
Yes, it is an option; the testing/tpu-approved/security-team file was
created on ftp-master so that the security team could do this directly,
but that file dates to Jul 2002, so I''m not sure it has any real data
in
it and certainly nothing recent.

You also have access to do this in your own hints file, though, using an
"approve" hint.
> you could also do it with mozilla and firefox, which haven''t
changed
> since sarge in there.
Same problem:  because of the FTBFS in unstable on alpha/arm/ia64, the
mozilla security updates for those arches were not accepted into
proposed-updates/t-p-u.

And firefox is also missing arm.

But if someone NMUed mozilla in unstable, the unaccepted binaries should
make their way back into t-p-u and could be approved.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/
-------------- 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/20050831/758b7ef3/attachment.pgp

On Tue, Aug 30, 2005 at 10:09:16AM -0400, Joey Hess
wrote:
> Can anyone suggest any more good candidates for DTSAs in the list of
> unfixed holes in testing? I''ve been trying to cover all the remote
> exploits and bad local exploits and aside from updating the kernel and
> mozilla thunderbird (which I can''t get to build), I don''t
see many
> other obvious candidates of that nature.
> I also looked at these:
>  - zlib: too young in unstable, would rather not add new upstreams of
>    core libs to the repo until we know what can go wrong
There''s zlib1g/1:1.2.2-4.sarge.2 in t-p-u on spohr for 10 of 11
architectures; getting the s390 binaries accepted requires ftp-master
intervention because a race condition was hit with the upload, but once
that''s done, we can push the same DSA binaries directly into testing...

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/
-------------- 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/20050830/c56343d7/attachment.pgp

On Tue, 2005-08-30 at 18:10 +0200, Moritz Muehlenhoff
wrote:
> Joey Hess wrote:
> > > > Can anyone suggest any more good candidates for DTSAs in the
list of
> > > > unfixed holes in testing? I''ve been trying to cover
all the remote
> > > > exploits and bad local exploits and aside from updating the
kernel and
> > > 
> > > I want to have a deeper look at this. Horms has some stuff
pending
> > > he hasn''t had the time to backport yet and some CVE
assignments are
> > > pending, but preparing updated recent 2.6.8 and 2.4.27 packages
> > > for etch seems like a good idea (as they are security/major fix
only
> > > anyway), until linux-2.6 has made it into testing.
> > 
> > The big problem with this is that it cannot be autobuilt since etch
> > still has all the different kernel source packages.
> 
> Yes, but plenty of porters in debian-kernel were building the kernels
> Horms prepared for Sarge, so they might be willing to do the same for
> Etch as well.
>  
Heh, getting porters to compile kernels is actually quite a long and
drawn out process.  Horms announced 2.6.8 kernel-source packages on Aug
17th; it''s now Aug 30, and we still don''t have builds for all
architectures (still waiting on mips; we finally got m68k images just
yesterday).  You may get better results helping us get linux-2.6 images
into testing.  :)

Steve Langasek wrote:
> There''s zlib1g/1:1.2.2-4.sarge.2 in t-p-u on spohr for 10 of 11
> architectures; getting the s390 binaries accepted requires ftp-master
> intervention because a race condition was hit with the upload, but once
> that''s done, we can push the same DSA binaries directly into
testing...
Hmm, if pushing DSA bins to testing is an option, you could also do it
with mozilla and firefox, which haven''t changed since sarge in there.

-- 
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/20050831/9070ca3a/attachment.pgp

Can anyone suggest any more good candidates for DTSAs in the list of
unfixed holes in testing? I''ve been trying to cover all the remote
exploits and bad local exploits and aside from updating the kernel and
mozilla thunderbird (which I can''t get to build), I don''t see
many
other obvious candidates of that nature.

I also looked at these:

 - drupal: should get into testing soon on its own
 - evolution: missing m68k build, otherwise a possibility
 - bluez-utils: needs bluez-libs updated too, which could be tricky
 - openvpn: well, possible, very young in unstable though
 - pdns: too young in unstable
 - php4: rc bugs, fix not in unstable
 - zlib: too young in unstable, would rather not add new upstreams of
   core libs to the repo until we know what can go wrong

-- 
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/20050830/dfbe51ba/attachment.pgp