Security team plans for the squeeze cycle

[Marc Brockschmidt-4]

Heya,

As announced on dda [RT1], we want to get an impression when releasing
Squeeze is feasible. We have proposed a (quite ambitious) freeze in December
2009, and some developers have noted that their planned changes wouldn't be
possible in this time frame. So, to find out when releasing would work for
most people, it would be great if you could answer the following questions:

Do you have any big changes planned? How much time would they take, and
what consequences are there for the rest of the project?

How many "big" transitions will the upcoming changes cause? When should those
happen? Can we do something to make them easier?

Thanks,
Marc

[RT1] http://lists.debian.org/debian-devel-announce/2009/07/msg00001.html

[Moritz Muehlenhoff]

Dear release people,

> As announced on dda [RT1], we want to get an impression when releasing
> Squeeze is feasible. We have proposed a (quite ambitious) freeze in December
> 2009, and some developers have noted that their planned changes wouldn't be
> possible in this time frame. So, to find out when releasing would work for
> most people, it would be great if you could answer the following questions:
>
> Do you have any big changes planned? How much time would they take, and
> what consequences are there for the rest of the project?
>
> How many "big" transitions will the upcoming changes cause? When should those
> happen? Can we do something to make them easier?

We discussed the hardening options at DebConf: We would like to see
-fstack-protector", "-D_FORTIFY_SOURCE=2", "-Wformat" and "-Werror=format-security"
set as default build flags through dpkg-buildpackage for at least i386 and
amd64 (some embedded archs don't implement it). We need to run more benchmarks
before filing a bug about this, but we don't expect much fallout caused by
build failures.

Shortening the release time frame causes some difficulties: Security support
for oldstable ends one year after the release of stable or with the release of
stable+1. Having a release one year after Lenny release will be difficult for
large organisations.

The initial announcement of the new release plans contained the idea to support
upgrades to Lenny to Debian 7.0. We don't have the resources to do that,
supporting the current state of affairs is difficult enough.

Cheers,
        Moritz


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

[Rainer Dorsch]

Moritz,

I remember sometime ago a posting telling that there is no testing security
support for a while, but did not yet see an announcement that squeeze
security support is in place. Did I miss it or is testing still w/o security
support?

Many thanks,
Rainer

Am Sonntag, 30. August 2009 schrieb Moritz Muehlenhoff:

> Dear release people,
>
> > As announced on dda [RT1], we want to get an impression when releasing
> > Squeeze is feasible. We have proposed a (quite ambitious) freeze in
> > December 2009, and some developers have noted that their planned changes
> > wouldn't be possible in this time frame. So, to find out when releasing
> > would work for most people, it would be great if you could answer the
> > following questions:
> >
> > Do you have any big changes planned? How much time would they take, and
> > what consequences are there for the rest of the project?
> >
> > How many "big" transitions will the upcoming changes cause? When should
> > those happen? Can we do something to make them easier?
>
> We discussed the hardening options at DebConf: We would like to see
> -fstack-protector", "-D_FORTIFY_SOURCE=2", "-Wformat" and
> "-Werror=format-security" set as default build flags through
> dpkg-buildpackage for at least i386 and amd64 (some embedded archs don't
> implement it). We need to run more benchmarks before filing a bug about
> this, but we don't expect much fallout caused by build failures.
>
> Shortening the release time frame causes some difficulties: Security
> support for oldstable ends one year after the release of stable or with the
> release of stable+1. Having a release one year after Lenny release will be
> difficult for large organisations.
>
> The initial announcement of the new release plans contained the idea to
> support upgrades to Lenny to Debian 7.0. We don't have the resources to do
> that, supporting the current state of affairs is difficult enough.
>
> Cheers,
>         Moritz

--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdorsch@...
jabber: rdorsch@...
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F  8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/

[Moritz Muehlenhoff]

On Wed, Sep 02, 2009 at 10:15:37PM +0200, Rainer Dorsch wrote:
> Moritz,
>
> I remember sometime ago a posting telling that there is no testing security
> support for a while, but did not yet see an announcement that squeeze
> security support is in place. Did I miss it or is testing still w/o security
> support?

The security team will deal with security support for Squeeze when
it's frozen.

Security support for testing between releases consists of two
parts:
- Making sure that security issues are promptly reported and fixed
in unstable. This was never stopped and works very well. As a result
fixes migrate to testing rather timely unless they're stuck in a
transition or such.
- Rebuilds of security fixes for testing. This is mostly inactive and
at the current point unlikely to resume to full support any time soon,
since it's quite time-consuming. It needs a automated solution, which
rebuilds a fix from unstable to the current testing, if Debian wants
to continue to provide security support for testing the the time
between releases.

Cheers,
        Moritz


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

[Petter Reinholdtsen]

[Moritz Muehlenhoff]
> if Debian wants to continue to provide security support for testing
> the the time between releases.

I believe it is a very god idea to provide security support for
testing also in the time between releases, and hope the security find
a way to do this with the available resources.

Happy hacking,
--
Petter Reinholdtsen


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

[Michael Gilbert]

On Sun, 13 Sep 2009 11:12:42 +0200 Petter Reinholdtsen wrote:

> [Moritz Muehlenhoff]
> > if Debian wants to continue to provide security support for testing
> > the the time between releases.
>
> I believe it is a very god idea to provide security support for
> testing also in the time between releases, and hope the security find
> a way to do this with the available resources.

as Moritz mentioned, the security team is indeed currently supporting
testing (via unstable updates that automatically transition).  it is an
inefficient use of the security team's time to prepare updates for
testing when they will shortly get overwritten by fixes transitioning
from unstable.

this justification is obviously incorrect once testing is frozen,
and, as Moritz stated, direct testing security support will begin then.

however, if there is an interest in direct support for testing in the
meantime, volunteers who are willing to spend their own time are very
welcome to do so. in fact, the security team is very welcoming of any
and all volunteers who would like to help in any area [0].

mike

[0] http://svn.debian.org/wsvn/secure-testing/doc/narrative_introduction


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

[Raphael Geissert-4]

Michael S Gilbert wrote:
[...]
>
> however, if there is an interest in direct support for testing in the
> meantime, volunteers who are willing to spend their own time are very
> welcome to do so. in fact, the security team is very welcoming of any
> and all volunteers who would like to help in any area [0].
>

I've been working on making security fixes migrate to testing as soon as
possible and done one DTSA for libsndfile and plan to continue helping
packages migrate in a timely manner. If anyone wants to help security
support please start by fixing RC bugs as they usually hold transitions or
block packages.

Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net



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

[Paul Hardy]

Marc,

On Sun, Aug 16, 2009 at 4:40 AM, Marc Brockschmidt
<marc@...> wrote:
> Heya,
>
> As announced on dda [RT1], we want to get an impression when releasing
> Squeeze is feasible....

> Do you have any big changes planned? How much time would they take, and
> what consequences are there for the rest of the project?

The Unicode Consortium just released Unicode 5.2 in October.  I didn't
want to reply to the above question before 5.2 was actually released.

I plan to have the almost 1000 new Unicode 5.2 glyphs in the Basic
Multilingual Plane added to the Debian unifont package by the end of
2009 (which fits in nicely with the new freeze date being in Spring
2010).  I'm also making a few tweaks to some existing glyphs as the
result of non-Debian requests that I've received.

GRUB uses the unifont package's unifont.hex source file.  I'll notify
the GRUB team ahead of time so they can test the new version and will
accommodate any needs they have for the file, as I did in the
unifont-1:5.1 releases.

Building the unifont-1:5.1 package was my first attempt at building
any Debian package.  It has multiple parts, and I finished adding the
last Unicode 5.1 glyph right before the freeze.  I would not have made
the freeze without help from my sponsor, Anthony Fok.  It looks like
this time I will have a little breathing room--and so will Anthony!

> Thanks,
> Marc
>
> [RT1] http://lists.debian.org/debian-devel-announce/2009/07/msg00001.html
>


Paul Hardy


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

[Felix Zielcke-3]

Ah seems like sometimes it's a good idea to read -release through the
webarchives.

>GRUB uses the unifont package's unifont.hex source file.  I'll notify
>the GRUB team ahead of time so they can test the new version and will
>accommodate any needs they have for the file, as I did in the
>unifont-1:5.1 releases.

Paul you're probable not happy to hear this, but we don't use anymore
unifont.hex. Our font system has changed and now we need a BDF font for
creating the GRUB 2 fonts.

We now use unifont.bdf from the bf-utf-source package.
Feel free to discuss it with me (us) if there's a better way to get a
unifont.bdf for building, but according to packages.d.o it's still the
only package which ships it.
I think there was a discussion on -devel that BDF fonts doestn't seem to
be that wanted, but as said above currently that's the only input format
for GRUB 2 fonts.


--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer


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

[Paul Hardy]

Hi Felix (and Robert).

On Fri, Nov 6, 2009 at 10:55 AM, Felix Zielcke <fzielcke@...> wrote:
>>GRUB uses the unifont package's unifont.hex source file.
>
> Paul you're probable not happy to hear this, but we don't use anymore
> unifont.hex. Our font system has changed and now we need a BDF font for
> creating the GRUB 2 fonts.

I was not aware of GRUB's change to BDF.

>
> We now use unifont.bdf from the bf-utf-source package.
> Feel free to discuss it with me (us) if there's a better way to get a
> unifont.bdf for building, but according to packages.d.o it's still the
> only package which ships it.

In the unifont source package, there's a gzipped version in
font/precompiled/unifont.bdf.gz.  I can create a unifont.bdf file from
it to copy to /usr/share/unifont, just as I do now for unifont.hex.  I
added the /usr/share/unifont contents just for GRUB.

> I think there was a discussion on -devel that BDF fonts doestn't seem to
> be that wanted, but as said above currently that's the only input format
> for GRUB 2 fonts.

Roman's original process for creating unifont was: 1) edit
unifont.hex, and 2) run hex2bdf to create unifont.bdf from the
unifont.hex file.

Debian policy forbids the installation of BDF fonts in a system font
directory.  I posted a message with a subject along the lines of "BDF
Considered Harmful?" on the debian-policy and debian-devel mailing
lists asking if support could be added for .bdf.gz fonts.  (xterm, for
example, runs fine with a .bdf font in a system font directory but not
with a .bdf.gz font.)  Nobody seemed in favor of the idea.  Some were
strongly opposed.

On the one hand I can appreciate the simplicity of only permitting one
bitmapped font format.  On the other, a lot of legacy Unix fonts were
created in BDF format.  There's no lossless round-trip conversion from
BDF to PCF and back to BDF where the resulting BDF file will be
identical to the original file.

Someone in those discussions did mention that it's still fine to have
a BDF font in a source package, so I am not really opposed to the BDF
ban in system font directories.  It was just worth asking.

I have about 700 glyphs left to draw to finish the Unicode 5.2
additions to the Basic Multilingual Plane.  When I'm finished, I'll
work on packaging a new version of unifont for Debian.  I can let you
know when I'm at that stage to work out details of what you'd like.
Of course if you use the unifont package, you'll have the latest
version font.

> --
> Felix Zielcke
> Proud Debian Maintainer and GNU GRUB developer
>

Paul Hardy


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