Re: Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye

[Florian Weimer]

* Matthias Klose:

> As background: OpenJDK 12 can only be built with 11, 13 with 12, 14 with 13, 
> 15
> with 14, 16 with 15. Only having 11 in bullseye would make backports more
> "interesting".

All recent OpenJDK releases can be built by themselves, right?

That's good enough for backports, I think.

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Florian Weimer]

* Florian Weimer:

>>  * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>>in GCC
>>(Raised by the GCC maintainer; carried over from stretch)
>
> I'm surprised to read this.  ppc64el features prominently in the
> toolchain work I do (though I personally do not work on the GCC side).

The ppc64le situation has been clarified.  It's now listed explicitly
as a primary architecture, as powerpc64le-unknown-linux-gnu:

  <https://gcc.gnu.org/gcc-11/criteria.html>

This has always been the intent, but I can understand that
distributions view powerpc64le-unknown-linux-gnu and
powerpc64-unknown-linux-gnu quite very different things.

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Florian Weimer]

* Paul Gevers:

>  * Concern for armel and armhf: only secondary upstream support in GCC
>(Raised by the GCC maintainer; carried over from stretch and buster)

glibc upstream lately has trouble finding qualified persons to
implement security fixes for the 32-bit Arm architecture.

>  * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>in GCC; Debian carries patches in binutils and GCC that haven't been
>integrated upstream even after a long time.
>(Raised by the GCC maintainer; carried over from stretch and buster)

I think I said this the last time, but the claim that there is no GCC
upstream support for ppc64le in GCC or binutils does not appear to be
grounded in fact. 8-/

Re: Should qpdf depend on gnutls?

[Florian Weimer]

* Jay Berkenbilt:

> I'm about to release qpdf 10. Someone contributed an openssl crypto
> provider. Do you think I should build with the qpdf packages for
> debian with 1) only gnutls, 2) only openssl, or 3) both gnutls and
> openssl? Option 3 allows users to select at runtime but makes qpdf
> dependent on both packages. I notice that systemd also depends on
> openssl. My impulse is to go with option 1 (gnutls only) because I
> really don't see any advantage in the OS package letting users
> choose at runtime which crypto to use, but including both cryptos
> probably doesn't ultimately affect what gets installed on anyone's
> system since openssl is basically always going to be there.

This seems to be more of a query for debian-devel, to be honest.

Two packages do not seem particularly useful to me. Since apt depends
on libgnutls30, I don't see how an OpenSSL backend for qpdf could
minimize installation size.  This suggests to me that you should stick
with GNUTLS for Debian.

Bug#928143: unblock: glibc/2.28-9

[Florian Weimer]

* Aurelien Jarno:

> - Fix for memusagestat's Makefile related code, which has no impact on
>   the generated code.

Sorry, I screwed that one up and had to revert it upstream for the 2.28
branch.  I don't think the bug introduced by this commit matters for
Debian at present, but it will cause problems if libpthread ever changes
internal ABI in buster because with the memusagestat Makefile change,
the installed libpthread is used instead of the newly built in-tree
libpthread.  Previously, the wrong headers were used, and while equally
invalid, this created no practical problems.

Thanks,
Florian

Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)

[Florian Weimer]

* Christoph Berg:

> with the update to glibc 2.28, collation aka sort ordering is
> changing:
>
> $ echo $LANG
> de_DE.utf8
> $ (echo 'a-a'; echo 'a a'; echo 'a+a'; echo 'aa') | sort
>
> stretch:
>   aa
>   a a
>   a-a
>   a+a
>
> buster:
>   a a
>   a+a
>   a-a
>   aa
>
> A vast number of locales is affected, including en_US, possibly all of
> them.
>
> For PostgreSQL, this means that the ordering of indexes on disk is
> becoming corrupt, and all "text" (varchar, char, ...) indexes need to
> be rebuilt. (And worse, if that is not done immediately, the tables
> might become corrupt because some tuples aren't index-visible anymore
> due to the incorrect btree ordering.)

That's fairly normal in a glibc update.  glibc upstream prefers it
this way.  I've discussed it several times with other glibc
maintainers.

My understanding is that ICU provides versioned collation tables,
which would allow you to avoid this issue.

  

> I've been thinking about this for some time, and the best I could come
> up so far is "raise a debconf note that people need to invoke REINDEX
> DATABASE". The open question about this plan is, how should this note
> be triggered.

That might not work for unique indices because locale data changes
could cause strings to sort the same that were distinct before the
update.

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

[Florian Weimer]

* Luke Kenneth Casson Leighton:

>  that is not a surprise to hear: the massive thrashing caused by the
> linker phase not being possible to be RAM-resident will be absolutely
> hammering the drives beyond reasonable wear-and-tear limits.  which is
> why i'm recommending people try "-Wl,--no-keep-memory".

Note that ld will sometimes stuff everything into a single RWX segment
as a result, which is not desirable.

Unfortunately, without significant investment into historic linker
technologies (with external sorting and that kind of stuff), I don't
think it is viable to build 32-bit software natively in the near
future.  Maybe next year only a few packages will need exceptions, but
the number will grow with each month.  Building on 64-bit kernels will
delay the inevitable because more address space is available to user
space, but that's probably 12 to 18 month extended life-time for
native building.

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Florian Weimer]

* Niels Thykier:

> armel/armhf:
> 
>
>  * Undesirable to keep the hardware running beyond 2020.  armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]

Fedora is facing an issue running armhf under virtualization on arm64:

  
  

Unless the discussion has moved somewhere where I can't follow it, no
one seems to have solid idea what is going on.  It's also not clear
that this configuration has substantial vendor or community support.
This makes me concerned that virtualization is a viable path forward
here.

(The discussion on the GCC list started off with a misdirection, sorry
about that.  The brief assumption that this was a hardware quirk is
likely quite wrong.)

>  * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>in GCC
>(Raised by the GCC maintainer; carried over from stretch)

I'm surprised to read this.  ppc64el features prominently in the
toolchain work I do (though I personally do not work on the GCC side).
>From my point of view, it's absolutely not in the same category as the
MIPS-based architectures.

Re: [release-notes/stretch] Release notes sign-off from the security team

[Florian Weimer]

* Julien Cristau:

> On Mon, Apr  3, 2017 at 20:43:08 +0200, Florian Weimer wrote:
>
>> * Niels Thykier:
>> 
>> > There is a security team related item in the release checklist where we
>> > need input from the you[1]:
>> >
>> > Items are:
>> >  * release-notes: Security Team signoff for lower supported packages
>> >
>> > Please review the release notes and file bugs for the missing items (if
>> > any) and let us know once this has been done.
>> 
>> I think you wanted to send this to the security team list, right?
>> 
>> I believe the current state is here:
>> 
>>   <https://release.debian.org/stretch/arch_qualify.html>
>> 
> The current state for the release notes is actually at
> https://www.debian.org/releases/stretch/releasenotes

It's not clear based on the architecture list in this document whether
there's going to be a s390 (31-bit) kernel, and what POWER
architectures are supported.

The release notes themselves still have FIXMEs under “Supported
architectures”.  The list currently goes like this:

32-bit PC (i386) and 64-bit PC (amd64)
64-bit ARM (arm64)
ARM EABI (armel)
ARMv7 (EABI hard-float ABI, armhf)
MIPS (mips (big-endian) and mipsel (little-endian))
64-bit little-endian MIPS (mips64el)
64-bit little-endian PowerPC (ppc64el)
IBM System z (s390x)

Re: [release-notes/stretch] Release notes sign-off from the security team

[Florian Weimer]

* Niels Thykier:

> There is a security team related item in the release checklist where we
> need input from the you[1]:
>
> Items are:
>  * release-notes: Security Team signoff for lower supported packages
>
> Please review the release notes and file bugs for the missing items (if
> any) and let us know once this has been done.

I think you wanted to send this to the security team list, right?

I believe the current state is here:

  

Although the gold bug for MIPS (#834147) has since been fixed.

armel and mips* are probably of highest risk from a long-term support
perspective.  I'm less worried about armhf, and powerpc (userland at
least) should still be fine for some time to come.

Re: Enabling PIE by default for Stretch

[Florian Weimer]

* Niels Thykier:

> Florian Weimer:
>> * Niels Thykier:
>> 
>>> [...]
>> 
>> Do you think that PIE-by-default makes BIND_NOW-by-default
>> unnecessary?
>> 
>> (The argument is that with PIE, it is much more difficult to get a
>> controlled GOT write.)
>> 
>
> Is this an implicit "Why did you not include BIND_NOW-by-default in this
> proposal"?

No, I mistakenly assumed it was way more widely used in Debian.

Re: Enabling PIE by default for Stretch

[Florian Weimer]

* Niels Thykier:

> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
>  * It is a substantial hardening feature
>  * Upstream has vastly reduced the performance penalty for x86
>  * The majority of all porters believe their release architecture is
>ready for it.
>  * We have sufficient time to solve any issues or revert if it turns out
>to be too problematic.

Do you think that PIE-by-default makes BIND_NOW-by-default
unnecessary?

(The argument is that with PIE, it is much more difficult to get a
controlled GOT write.)

Re: [Stretch] Status for architecture qualification

[Florian Weimer]

> In other words, i don't think a s390x box will ever just die.

I'm sure “death” encompasses all events which might lead Debian to
lose access to relevant hardware.  It's not just about faults with a
piece of equipment.

Re: [Stretch] Status for architecture qualification

[Florian Weimer]

* Lennart Sorensen:

> There are a lot of 32bit powerpc chips still going into embedded systems
> being built today.  They are not going away anytime soon.

Do they implement the ISA required by the existing Debian port?

Bug#824872: jessie-pu: package nspr/2:4.12-2+deb8u1

[Florian Weimer]

* Guido Günther:

> Note that the only (as to my understanding) serious regression has been
> pointed out by Florian as well:
>
> https://lists.debian.org/debian-lts/2015/11/msg00037.html
> https://bugzilla.redhat.com/show_bug.cgi?id=1260698
>
> and it's unclear if this part of the ABI.

The practical impact seems pretty low.

There is another ABI issue:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1247021

But I think we are rebasing past the introduction of this struct and
its change, so it wouldn't impact Debian stable.

Removal of docker.io from jessie

[Florian Weimer]

The security team has concerns that docker.io cannot be maintained in
jessie.

I asked upstream about the Go version commitment (we cannot rebase to
Go 1.4 or later in jessie because it could break user code):

  https://groups.google.com/forum/#!topic/docker-dev/BjNmlgifZ5c

(Not sure if this link will work, it obviously requires Javascript.
It should point to the docker-dev thread, “Go version requirement”,
started on 2015-03-15.)

I think the Go version issue has been adequately addressed, but other
parts of the thread show that there is no clear plan how to rebase
docker.io to a new upstream version once this becomes necessary.
Hence our concerns about maintainability.

(The rebase question is not entirely theoretical.  Upstream has
previously acknowledged that “the v1 registry has a flawed design”:

  https://news.ycombinator.com/item?id=8789775

The v1 registry protocol is what is implemented in docker.io 1.3.3.
Debian does not run its own trusted registry, so our users are fully
exposed to these design issues.)


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k2y87p0h@mid.deneb.enyo.de

Re: [SRM] krb5 changelog missing CVE

[Florian Weimer]

* Philipp Kern:

 On Wed, Jan 04, 2012 at 07:48:27AM +0100, Florian Weimer wrote:
 * Adam D. Barratt:
  Apologies if I'm missing something, but if the packages are already in
  the queue on security-master, wouldn't it be simpler (and possibly more
  logical) to release them from there?  Hmmm, looking at the tracker,
  maybe because they're just DoS issues?
 Yes, and we'd have to deal with lenny in some way.

 Why is that, given that according to the tracker, lenny isn't even
 affected?  I'd appreciate a fix for a remote DoS of a network service
 through security, to be honest.

Oh well, squeeze-security it is.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hb0be3yc@mid.deneb.enyo.de

Re: [SRM] krb5 changelog missing CVE

[Florian Weimer]

* Sam Hartman:

 Florian Weimer noticed that the krb5 changelog in squeeze was missing a
 CVE that was fixed in the patch applied.
 He proposes to make a new upload that corrects the changelog so that
 people who track security issues from the changelog will find the fix:

Sorry, there seems to be a slight misunderstanding.  The changelog was
indeed incorrect, but even that upload never made it to the archive.

To clarify, we would like to fix the issues described in this
announcement:

From: Tom Yu t...@mit.edu
Subject: MITKRB5-SA-2011-006 KDC denial of service vulnerabilities  
[CVE-2011-1527 CVE-2011-1528 CVE-2011-1529]
To: kerberos-annou...@mit.edu
Date: Tue, 18 Oct 2011 14:06:02 -0400
Message-ID: ldvlisiuqd1@cathode-dark-space.mit.edu

(CVE-2011-1527 does not affect squeeze.)

We already have packages built for (all?) 13 architectures.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obuk4n7l@mid.deneb.enyo.de

Re: [SRM] krb5 changelog missing CVE

[Florian Weimer]

* Sam Hartman:

 Florian == Florian Weimer f...@deneb.enyo.de writes:

 Florian * Sam Hartman:
  Florian Weimer noticed that the krb5 changelog in squeeze was
  missing a CVE that was fixed in the patch applied.  He proposes
  to make a new upload that corrects the changelog so that people
  who track security issues from the changelog will find the fix:

 Florian Sorry, there seems to be a slight misunderstanding.  The
 Florian changelog was indeed incorrect, but even that upload never
 Florian made it to the archive.

 I thought the issues were already fixed in squeeze2.
 I thought the only question was the changelog entry and documenting the
 issues.

No, the first fixed version was squeeze3.  You uploaded that in
October last year, but we failed to publish it at that time.

For completeness, I'm attaching the debdiff between squeeze2 and
squeeze5.


diff -u krb5-1.8.3+dfsg/debian/changelog krb5-1.8.3+dfsg/debian/changelog
--- krb5-1.8.3+dfsg/debian/changelog
+++ krb5-1.8.3+dfsg/debian/changelog
@@ -1,3 +1,12 @@
+krb5 (1.8.3+dfsg-4squeeze5) squeeze-security; urgency=high
+
+  * CVE-2011-1529: null pointer dereference in KDC LDAP back end,
+Closes: #629558
+  * CVE-2011-1528: assertion failure in multiple KDC back ends
+regarding account lockout
+
+ -- Sam Hartman hartm...@debian.org  Wed, 19 Oct 2011 11:55:43 -0400
+
 krb5 (1.8.3+dfsg-4squeeze2) stable; urgency=low
 
   * Upstream ticket 6852: permit gss_set_allowable_enctypes to restirct
diff -u krb5-1.8.3+dfsg/src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c 
krb5-1.8.3+dfsg/src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c
--- krb5-1.8.3+dfsg/src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c
+++ krb5-1.8.3+dfsg/src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c
@@ -131,6 +131,7 @@
 CHECK_LDAP_HANDLE(ldap_context);
 
 if (is_principal_in_realm(ldap_context, searchfor) != 0) {
+st = KRB5_KDB_NOENTRY;
 *more = 0;
 krb5_set_error_message (context, st, Principal does not belong to 
realm);
 goto cleanup;
only in patch2:
unchanged:
--- krb5-1.8.3+dfsg.orig/src/plugins/kdb/ldap/libkdb_ldap/lockout.c
+++ krb5-1.8.3+dfsg/src/plugins/kdb/ldap/libkdb_ldap/lockout.c
@@ -150,15 +150,25 @@
 return 0;
 }
 
+if (entry == NULL)
+return 0;
+
 code = lookup_lockout_policy(context, entry, max_fail,
  failcnt_interval,
  lockout_duration);
 if (code != 0)
 return code;
 
-entry-mask = 0;
+/*
+ * Don't continue to modify the DB for an already locked account.
+ * (In most cases, status will be KRB5KDC_ERR_CLIENT_REVOKED, and
+ * this check is unneeded, but in rare cases, we can fail with an
+ * integrity error or preauth failure before a policy check.)
+ */
+if (locked_check_p(context, stamp, max_fail, lockout_duration, entry))
+return 0;
 
-assert (!locked_check_p(context, stamp, max_fail, lockout_duration, 
entry));
+entry-mask = 0;
 
 if (status == 0  (entry-attributes  KRB5_KDB_REQUIRES_PRE_AUTH)) {
 /*
only in patch2:
unchanged:
--- krb5-1.8.3+dfsg.orig/src/plugins/kdb/db2/lockout.c
+++ krb5-1.8.3+dfsg/src/plugins/kdb/db2/lockout.c
@@ -158,13 +158,23 @@
 return 0;
 }
 
+if (entry == NULL)
+return 0;
+
 code = lookup_lockout_policy(context, entry, max_fail,
  failcnt_interval,
  lockout_duration);
 if (code != 0)
 return code;
 
-assert (!locked_check_p(context, stamp, max_fail, lockout_duration, 
entry));
+/*
+ * Don't continue to modify the DB for an already locked account.
+ * (In most cases, status will be KRB5KDC_ERR_CLIENT_REVOKED, and
+ * this check is unneeded, but in rare cases, we can fail with an
+ * integrity error or preauth failure before a policy check.)
+ */
+if (locked_check_p(context, stamp, max_fail, lockout_duration, entry))
+return 0;
 
 if (status == 0  (entry-attributes  KRB5_KDB_REQUIRES_PRE_AUTH)) {
 /*


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739bw4lf9@mid.deneb.enyo.de

Re: [SRM] krb5 changelog missing CVE

[Florian Weimer]

* Adam D. Barratt:

 On Tue, 2012-01-03 at 20:09 +0100, Florian Weimer wrote:
 * Sam Hartman:
 
  Florian Weimer noticed that the krb5 changelog in squeeze was missing a
  CVE that was fixed in the patch applied.
  He proposes to make a new upload that corrects the changelog so that
  people who track security issues from the changelog will find the fix:
 
 Sorry, there seems to be a slight misunderstanding.  The changelog was
 indeed incorrect, but even that upload never made it to the archive.
 [...]
 We already have packages built for (all?) 13 architectures.

 Based on that final comment, I assume the updates will be released via
 the security archive and there's nothing we (the release team) need to
 do right now?

No, I would like to take them from the queue and upload them directly
to the main archive.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k45835cx@mid.deneb.enyo.de

Re: [SRM] krb5 changelog missing CVE

[Florian Weimer]

* Adam D. Barratt:

 Apologies if I'm missing something, but if the packages are already in
 the queue on security-master, wouldn't it be simpler (and possibly more
 logical) to release them from there?  Hmmm, looking at the tracker,
 maybe because they're just DoS issues?

Yes, and we'd have to deal with lenny in some way.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4zgezes@mid.deneb.enyo.de

Re: Bug#645881: critical update 29 available

[Florian Weimer]

* Philipp Kern:

 sun-java6 is sadly still a very high profile package.  I won't go and
 break all those installations which force sun-java6 over openjdk-6
 locally, either in unattended installations or through other means.

It's really unfortunate that most of those installations seem to need
sun-java6-plugin, which the package which is actually dangerous to
install.  (Presumably, only the first stage payload is pure Java, and
the dropped malware won't run, but it's a bit unsettling.)  At least
this package doesn't seem to be install without explicit request, so
it's not extremely bad.

 openjdk-6 might well be a viable replacement in wheezy, but there
 are no efforts to backport those compatibility patches that might be
 in newer versions.

We will have to switch to a different IcedTea version in squeeze
because the 1.8 branch we currently use will cease to receive security
fixes soonish, probably after the next round of updates.  If we switch
to branch where the plugin is separate (1.10 and later, IIRC), we
could start fixing compatibility issues more aggressively if we wanted
to.

 openjdk-6 might well be a viable replacement in wheezy, but there
 are no efforts to backport those compatibility patches that might be
 in newer versions.

I doubt it.  The incompatibilities do not vanish, unless there is a
critical mass of users who also contribute bug fixes.  We just don't
seem to be there yet.

(I also doubt that Oracle can drop security support for the Java 6
plugin in mid-2012, for mostly the same reason, at lesat if they don't
want to be entirely reckless.  They haven't even started pushing
Java 7 to end users yet.)


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wra3i6q4@mid.deneb.enyo.de

Re: Bug#645881: critical update 29 available

[Florian Weimer]

* Matthias Klose:

 On 12/11/2011 01:07 PM, Holger Levsen wrote:
 Hi,
 
 On Sonntag, 11. Dezember 2011, Philipp Kern wrote:
 sorry, but I'd rather like to have an announcement that it has a bug,
 
 me too, for all the reasons Philipp noted.
 
 It's also trivial to download the fixed jdk from oracle and build a fixed
 package, so IMHO an announcement containing these information plus no
 removal would be best:

 the DLJ bundles were created because you are not allowed to re-distribute the
 jdk packages from oracle. Did that change recently?

The main difference seems to be this (DLJ first):

| [...] Sun also grants you a non-exclusive, non-transferable,
| royalty-free limited license to reproduce and distribute the
| Software [...]  provided that: (b) the Software is distributed with
| your Operating System, and such distribution is solely for the
| purposes of running Programs under the control of your Operating
| System and designing, developing and testing Programs to be run
| under the control of your Operating System; [...]

| [...] Oracle grants you a non-exclusive, non-transferable, limited
| license without fees to reproduce and distribute the Software,
| provided that (i) you distribute the Software complete and
| unmodified and only bundled as part of, and for the sole purpose of
| running, your Programs, [...]

Other problematic clauses (indemnification, no bundling with
reimplementatiosn of java.* classes and so on) are also part of the
DLJ.

(I still don't understand why the DLJ was suitable for non-free, so
I'm clearly not qualified to judge these license matters for Debian.)


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkeylvww@mid.deneb.enyo.de

Re: Bug#645881: critical update 29 available

[Florian Weimer]

* Moritz Mühlenhoff:

 Florian, what's the status of openjdk6 for stable/oldstable?

I've released the pending update for squeeze.  lenny will eventually
follow, and so will the pending updates for squeeze, but judging by my
past performance, it will take a while.

If someone else wants to work on these updates, I'll gladly share what
I've learnt about the packaging.


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjl4vx1i@mid.deneb.enyo.de

Re: Bug#645881: critical update 29 available

[Florian Weimer]

* Moritz Muehlenhoff:

 As for stable/oldstable: I noticed that Red Hat provided packages for
 update 29 for RHEL 4 (RHEL 5 onwards use OpenJDK): 
 http://lwn.net/Articles/463919/

If anyone remembers the rationale behind the DLJ, perhaps they can
check if the current BCL matches our needs, too?  The licensing
conditions for the stock JDK distribution probably have changed since
the Oracle acquisition, and perhaps these changes are sufficient to
permit redistribution by Debian.

I have also uploaded the fixes for openjdk-6 to security-master (for
squeeze).  It's currently stuck in the unchecked queue, along with the
still-missing previous update for lenny.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lisebtm5@mid.deneb.enyo.de

Re: Bug#622817: perl: CVE-2011-1487: taint laundering in lc, uc

[Florian Weimer]

* Dominic Hargreaves:

  Okay, then we should release a DSA for it, so that the breakage is
  more easily blamed on this particular change, and that it's less
  confusing if we have to issue follow-up DSAs.  Perhaps late May or
  early June would be a convenient release date?
 
 Wasn't the earlier consensus that this only affects Perl scripts, which
 are already insecure?

 I don't think we've seen any discussion of this; could you elaborate?

There was some discussion prior to filing the bug report, sorry.

Anyway, we should probably push the fix to lenny and squeeze at this
point.  (See above for part of my rationale for that.)

I can grab
0002-CVE-2011-1487-lc-uc-first-fail-to-taint-the-returned.patch and
apply it to squeeze  lenny if you want me to.  Are there any other
pending changes I should pick up?


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877h8ly1sy@mid.deneb.enyo.de

Re: Bug#622817: perl: CVE-2011-1487: taint laundering in lc, uc

[Florian Weimer]

* Adam D. Barratt:

 I do share Florian's concern about the potential breakage as a result of
 the change.  Do we have any idea how many packages in {old,}stable would
 be affected and to what degree?  Particularly in the case of oldstable,
 with its four month update cycle, fixing packages broken by the change
 could be somewhat painful.

Okay, then we should release a DSA for it, so that the breakage is
more easily blamed on this particular change, and that it's less
confusing if we have to issue follow-up DSAs.  Perhaps late May or
early June would be a convenient release date?


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqo3bt84@mid.deneb.enyo.de

Re: PostgreSQL security update

[Florian Weimer]

* Martin Pitt:

 PostgreSQL just announced new microreleases which fix one security
 issue and several bugs. Details at

   http://www.postgresql.org/about/news.1289

 I already uploaded 8.4.7 and 9.0.3 to unstable with the fixes.

 I prepared a lenny update in [1] which is ready for upload. I built
 the binaries in a clean lenny chroot, and confirm that they pass both
 the upstream and my postgresql-common test suite. [2] is the complete
 debdiff, [3] the debdiff minus po diff and documentation noise (much
 easier to read).

 How do you want me to handle the update for squeeze? 8.3.13 didn't get
 uploaded to squeeze because it was deemed too late [4], but 8.3.13 was
 only a normal bug fix update. As this update will go to -security, is
 that reasonably independent from squeeze itself to upload it now, or
 do you want me to hold it for now?

Thanks for preparing updated packages.

You've confused the versions, I'm afraid.

For lenny, we need an 8.3 update.  For squeeze, 8.4.  If 8.4.7 can
propagate to squeeze from unstable, that would be the easiest option.
Otherwise, we need to do a testing-security or stable-security upload
for postgresql-8.4 with a version number lower than 8.4.7, but higher
than 8.4.5-0squeeze2.

As usual for PostgreSQL, we can release the 8.3.13 upstream version as
a security update for lenny, thanks to the excellent track record.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ei7rgz6b@mid.deneb.enyo.de

Re: PostgreSQL security update

[Florian Weimer]

* Martin Pitt:

 Florian Weimer [2011-02-01 23:36 +0100]:
 You've confused the versions, I'm afraid.

 Erk, sorry. That was just in the email, though.
 
 For lenny, we need an 8.3 update.

 http://people.debian.org/~mpitt/psql/lenny/ has 8.3.14, as it should
 be.

 Want me to dput this?

Yes, please, to security-master.  Thanks in advance.

 Anyway, in case it works better with -security (separate archive and
 buildds, thus no danger of missing the release deadline due to buildd
 lag?), I prepared a 8.4.7-0squeeze1 testing-security update in

  http://people.debian.org/~mpitt/psql/squeeze/

 (passing all tests).

I think you can upload this, too.  We might not be able to release the
update if the release comes in-between, but then we can just bump the
version number and do a new upload.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871v3q995f@mid.deneb.enyo.de

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

[Florian Weimer]

* tony mancill:

 On 01/14/2011 11:46 AM, Florian Weimer wrote:
 * tony mancill:
 
 As per Section 5.8.5 of the Developer's Reference, I'd like to get
 confirmation from the Security Team that they are anticipating and
 approve of the upload of the new source version.  (My apologies if this
 has already been covered; I joined the thread already in progress.)
 
 Would you please show us the debdiff to the version in squeeze, and
 the list of dependencies of the .deb file?  Alternatively, please put
 the files on people.debian.org, so that we can have a look at them
 before the upload.  Thanks for your support in this matter.
 
 Do you plane to switch to IcedTea 1.9 or a later version during the
 squeeze release?

 Because the debdiff is quite large (from 6b11 to 6b18), I've uploaded
 the build to people.debian.org.

For that reason, I asked for a debdiff against the *squeeze*
version. 8-)

What is the following change about?

--- openjdk-6-6b18-1.8.3/Makefile.in
+++ openjdk-6-6b18-1.8.3.orig/Makefile.in
@@ -800,7 +800,6 @@
--enable-zero $(am__append_25) --disable-docs $(filter-out \
'--with-gcj-home=% '--with-ecj=% '--with-java=% \
'--with-javah=% '--with-rmic=% '--with-additional-vms=% \
-   '--with-hotspot-build=% '--with-hotspot-src-zip=% \
'--with-openjdk '--with-openjdk=% , $(CONFIGURE_ARGS)) $(if \
$(findstring --with-openjdk-src-zip=, $(CONFIGURE_ARGS)),, \
--with-openjdk-src-zip=$(abs_top_builddir)/$(OPENJDK_SRC_ZIP)) \
@@ -811,7 +810,7 @@
BUILD_JAXWS=false ALT_JAXWS_DIST=$(ICEDTEA_BUILD_DIR)/jaxws/dist \
BUILD_CORBA=false ALT_CORBA_DIST=$(ICEDTEA_BUILD_DIR)/corba/dist \
BUILD_JDK=false \
+   DISTRIBUTION_PATCHES='$(foreach p,$(DISTRIBUTION_PATCHES),$(if 
$(findstring cacao,$(p)),,$(p)))'
-   DISTRIBUTION_PATCHES='$(foreach p,$(DISTRIBUTION_PATCHES),$(if 
$(findstring cacao,$(p)),,$(subst -hs17,-original,$(p'
 
This is present both relative to squeeze and to a direct rebuild for
lenny (according to Matthias Klose's suggestion), so it seems that you
applied it.

 So everyone's clear, I did this under the impression that what was
 needed for lenny was essentially a binary build of the current version
 in testing.

AFAICT, your packages will introduce pulseaudio support and replace
the browser plugin code (which might need updating the conflict with
icedtea-gcjwebplugin).  If you follow Matthias' suggestion (plus the
ca-certificates-java patch), then you end up with something closer to
the lenny version.  Which approach carries less risk, in your opinion?


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871v48ytc1@mid.deneb.enyo.de

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

[Florian Weimer]

* Matthias Klose:

 get the files from testing/unstable  touch debian/control.in 
 debian/rules debian/control

I end up with this:

mkdir -p /tmp/buildd/openjdk-6-6b18-1.8.3/build/plugin/icedteanp  \
cd /tmp/buildd/openjdk-6-6b18-1.8.3/build/plugin/icedteanp  \
x86_64-linux-gnu-g++ -g -O2 \
  -DJDK_UPDATE_VERSION=\18\ \
  -DPLUGIN_VERSION=\IcedTea6 1.8.3 (6b18-1.8.3-2~lenny1)\ \
  -DMOZILLA_VERSION_COLLAPSED=1090019 \
  -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   \
  -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include 
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 
-I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1   \
  -I/usr/include/xulrunner-1.9/stable -I/usr/include/nspr   \
  -fPIC -o 
/tmp/buildd/openjdk-6-6b18-1.8.3/build/plugin/icedteanp/IcedTeaNPPlugin.o -c 
/tmp/buildd/openjdk-6-6b18-1.8.3/build/../plugin/icedteanp/IcedTeaNPPlugin.cc
In file included from 
/tmp/buildd/openjdk-6-6b18-1.8.3/build/../plugin/icedteanp/IcedTeaJavaRequestProcessor.h:46,
 from 
/tmp/buildd/openjdk-6-6b18-1.8.3/build/../plugin/icedteanp/IcedTeaScriptablePluginObject.h:49,
 from 
/tmp/buildd/openjdk-6-6b18-1.8.3/build/../plugin/icedteanp/IcedTeaNPPlugin.cc:51:
/tmp/buildd/openjdk-6-6b18-1.8.3/build/../plugin/icedteanp/IcedTeaNPPlugin.h:43:27:
 error: nsThreadUtils.h: No such file or directory
/tmp/buildd/openjdk-6-6b18-1.8.3/build/../plugin/icedteanp/IcedTeaNPPlugin.cc:56:31:
 error: nsIPluginInstance.h: No such file or directory

I suppose we need to disable building the plugin on lenny (it's in a
separate package there anyway, I think).  Is there an easy way to do
this?


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vd1pw4rq@mid.deneb.enyo.de

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

[Florian Weimer]

* Torsten Werner:

 Hi,

 On Sun, Jan 16, 2011 at 11:09 AM, Julien Cristau jcris...@debian.org wrote:
 How does that follow?  These kinds of updates are sort of allowed for
 sun-java6 because it's non-free so there's no choice.  That does not
 apply to openjdk, as far as I know.

 I think that openjdk is not that different. Oracle does not release
 small patches. They release several non-free binary tarballs
 (sun-java6) and a GPL-2 source tarball (openjdk). It is almost
 impossible to extract individual fixes from the source tarball.

Have there been any OpenJDK 6 releases at all?

AFAICT, Debian is actually shipping IcedTea releases, but those are
re-rebranded as IcedTea.

(Now building with with_plugin_pkg=no, let's see if the result will be
usable.)


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lj2lw1qs@mid.deneb.enyo.de

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

[Florian Weimer]

* Florian Weimer:

 AFAICT, Debian is actually shipping IcedTea releases, but those are
 re-rebranded as IcedTea.

Sorry, re-rebranded as OpenJDK.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vd1pum3t@mid.deneb.enyo.de

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

[Florian Weimer]

* tony mancill:

 As per Section 5.8.5 of the Developer's Reference, I'd like to get
 confirmation from the Security Team that they are anticipating and
 approve of the upload of the new source version.  (My apologies if this
 has already been covered; I joined the thread already in progress.)

Would you please show us the debdiff to the version in squeeze, and
the list of dependencies of the .deb file?  Alternatively, please put
the files on people.debian.org, so that we can have a look at them
before the upload.  Thanks for your support in this matter.

Do you plane to switch to IcedTea 1.9 or a later version during the
squeeze release?


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y66nb759@mid.deneb.enyo.de

squeeze upload for eglibc due to DSA-2122-2

[Florian Weimer]

I would like to make an upload of eglibc to address DSA-2122-2 (the
first round of patches for the $ORIGIN/LD_AUDIT issue does not cover
all corner cases, unfortunately).  The changes match those in
2.7-18lenny7, which are based almost verbatim on the upstream patches
(except for whitespace changes and one manual conflict resultion, see
the attachments; cvs-origin-suid.diff and
any/local-audit-pathless.diff).

Should I push this through testing-security, testing-proposed-updates
or unstable?  Have you got any preferences about version numbers?
commit 22cd1c9bcf57c5829d65b6da825f7a459d40c9eb
Author: Andreas Schwab sch...@redhat.com
Date:   Sun Oct 24 20:40:14 2010 -0400

Don't expand DST twice in dl_open

diff --git a/elf/dl-open.c b/elf/dl-open.c
index 754a263..c394b3f 100644
--- a/elf/dl-open.c
+++ b/elf/dl-open.c
@@ -221,36 +221,6 @@ dl_open_worker (void *a)
 
   assert (_dl_debug_initialize (0, args-nsid)-r_state == RT_CONSISTENT);
 
-  /* Maybe we have to expand a DST.  */
-  if (__builtin_expect (dst != NULL, 0))
-{
-  size_t len = strlen (file);
-  size_t required;
-  char *new_file;
-
-  /* Determine how much space we need.  We have to allocate the
-	 memory locally.  */
-  required = DL_DST_REQUIRED (call_map, file, len, _dl_dst_count (dst, 0));
-
-  /* Get space for the new file name.  */
-  new_file = (char *) alloca (required + 1);
-
-  /* Generate the new file name.  */
-  _dl_dst_substitute (call_map, file, new_file, 0);
-
-  /* If the substitution failed don't try to load.  */
-  if (*new_file == '\0')
-	_dl_signal_error (0, dlopen, NULL,
-			  N_(empty dynamic string token substitution));
-
-  /* Now we have a new file name.  */
-  file = new_file;
-
-  /* It does not matter whether call_map is set even if we
-	 computed it only because of the DST.  Since the path contains
-	 a slash the value is not used.  See dl-load.c.  */
-}
-
   /* Load the named object.  */
   struct link_map *new;
   args-map = new = _dl_map_object (call_map, file, 0, lt_loaded, 0,
commit 96611391ad8823ba58405325d78cefeae5cdf699
Author: Andreas Schwab sch...@redhat.com
Date:   Thu Dec 9 15:00:59 2010 +0100

Ignore origin of privileged program

diff --git a/elf/dl-object.c b/elf/dl-object.c
index 5d15ce1..a34e902 100644
--- a/elf/dl-object.c
+++ b/elf/dl-object.c
@@ -220,6 +220,9 @@ _dl_new_object (char *realname, const char *libname, int type,
 out:
   new-l_origin = origin;
 }
+  else if (INTUSE(__libc_enable_secure)  type == lt_executable)
+/* The origin of a privileged program cannot be trusted.  */
+new-l_origin = (char *) -1;
 
   return new;
 }
commit 8e9f92e9d5d7737afdacf79b76d98c4c42980508
Author: Andreas Schwab sch...@redhat.com
Date:   Sun Oct 24 21:43:15 2010 -0400

Require suid bit on audit objects in privileged programs

diff --git a/elf/dl-deps.c b/elf/dl-deps.c
index a58de5c..a51fb6e 100644
--- a/elf/dl-deps.c
+++ b/elf/dl-deps.c
@@ -62,7 +62,7 @@ openaux (void *a)
 {
   struct openaux_args *args = (struct openaux_args *) a;
 
-  args-aux = _dl_map_object (args-map, args-name, 0,
+  args-aux = _dl_map_object (args-map, args-name,
 			  (args-map-l_type == lt_executable
 			   ? lt_library : args-map-l_type),
 			  args-trace_mode, args-open_mode,
diff --git a/elf/dl-load.c b/elf/dl-load.c
index a7162eb..aa8738f 100644
--- a/elf/dl-load.c
+++ b/elf/dl-load.c
@@ -1812,7 +1812,7 @@ open_verify (const char *name, struct filebuf *fbp, struct link_map *loader,
if MAY_FREE_DIRS is true.  */
 
 static int
-open_path (const char *name, size_t namelen, int preloaded,
+open_path (const char *name, size_t namelen, int secure,
 	   struct r_search_path_struct *sps, char **realname,
 	   struct filebuf *fbp, struct link_map *loader, int whatcode,
 	   bool *found_other_class)
@@ -1894,7 +1894,7 @@ open_path (const char *name, size_t namelen, int preloaded,
 	  /* Remember whether we found any existing directory.  */
 	  here_any |= this_dir-status[cnt] != nonexisting;
 
-	  if (fd != -1  __builtin_expect (preloaded, 0)
+	  if (fd != -1  __builtin_expect (secure, 0)
 	   INTUSE(__libc_enable_secure))
 	{
 	  /* This is an extra security effort to make sure nobody can
@@ -1963,7 +1963,7 @@ open_path (const char *name, size_t namelen, int preloaded,
 
 struct link_map *
 internal_function
-_dl_map_object (struct link_map *loader, const char *name, int preloaded,
+_dl_map_object (struct link_map *loader, const char *name,
 		int type, int trace_mode, int mode, Lmid_t nsid)
 {
   int fd;
@@ -2067,7 +2067,8 @@ _dl_map_object (struct link_map *loader, const char *name, int preloaded,
 	  for (l = loader; l; l = l-l_loader)
 	if (cache_rpath (l, l-l_rpath_dirs, DT_RPATH, RPATH))
 	  {
-		fd = open_path (name, namelen, preloaded, l-l_rpath_dirs,
+		fd = open_path (name, namelen, mode  __RTLD_SECURE,
+l-l_rpath_dirs,
 realname, fb, loader, LA_SER_RUNPATH,
 found_other_class);
 		if 

Re: Bug#604016: Please support 3w-sas controllers

[Florian Weimer]

* Adam D. Barratt:

 On Wed, 2010-12-01 at 16:12 +, Florian Weimer wrote:
 * Julien Cristau:
 
  On Mon, Nov 22, 2010 at 12:11:43 +0100, Giuseppe Iuculano wrote:
 
  Release Team,
  
  Would this be an acceptable change for a freeze exception?
  
  Yes (assuming it's properly tested).
 
 Okay, I'll test an isolated backport tomorrow, using the hardware in
 question.

 Did you have any luck with that?

The attached patch was tested with a 9750 controller and a 9500S
controller.  Basic SMART functionality still works.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
diff -Nru smartmontools-5.39.1+svn3124/debian/changelog 
smartmontools-5.39.1+svn3124/debian/changelog
--- smartmontools-5.39.1+svn3124/debian/changelog   2010-07-13 
13:17:33.0 +0200
+++ smartmontools-5.39.1+svn3124/debian/changelog   2010-12-23 
11:08:50.0 +0100
@@ -1,3 +1,9 @@
+smartmontools (5.39.1+svn3124-2) unstable; urgency=low
+
+  * 3w-sas support (from upstream changeset r3128)
+
+ -- Florian Weimer fwei...@bfk.de  Thu, 23 Dec 2010 11:08:19 +0100
+
 smartmontools (5.39.1+svn3124-1) unstable; urgency=low
 
   * [1e46e09] Set state and attribute file directory to
diff -Nru smartmontools-5.39.1+svn3124/debian/patches/3w-sas 
smartmontools-5.39.1+svn3124/debian/patches/3w-sas
--- smartmontools-5.39.1+svn3124/debian/patches/3w-sas  1970-01-01 
01:00:00.0 +0100
+++ smartmontools-5.39.1+svn3124/debian/patches/3w-sas  2010-12-23 
11:07:56.0 +0100
@@ -0,0 +1,405 @@
+Author: chrfranke chrfra...@4ea69e1a-61f1-4043-bf83-b5c94c648137
+Date:   Tue Jul 27 13:08:31 2010 +
+
+Linux: Support SATA drives on LSI 3ware 9750 controllers (ticket #86).
+
+Index: smartmontools-5.39.1+svn3124/CHANGELOG
+===
+--- smartmontools-5.39.1+svn3124.orig/CHANGELOG2010-07-12 
21:21:00.0 +0200
 smartmontools-5.39.1+svn3124/CHANGELOG 2010-12-23 11:05:12.103063859 
+0100
+@@ -86,6 +86,10 @@
+This fixes build on QNX (ticket #1).
+Thanks to Stefan (stevestereo) for testing.
+ 
++  [CF] Linux: Support SATA drives on LSI 3ware 9750 controllers.
++   Patch provided by Victor Payno (ticket #86).
++   Modified to avoid duplicate code.
++
+   [CF] drivedb.h update:
+- WD Caviar Green (Adv. Format) family
+ 
+Index: smartmontools-5.39.1+svn3124/NEWS
+===
+--- smartmontools-5.39.1+svn3124.orig/NEWS 2010-06-11 18:21:25.0 
+0200
 smartmontools-5.39.1+svn3124/NEWS  2010-12-23 11:05:12.103063859 +0100
+@@ -22,6 +22,7 @@
+   SCT Error Recovery Control time limit.
+ - smartctl options '--scan, --scan-open'.
+ - Linux: Add '/dev/sd[a-c][a-z]' to smartd DEVICESCAN.
++- Linux: Support SATA drives on LSI 3ware 9750 controllers.
+ - Windows: Read 'drivedb.h' and 'smartd.conf' from exe directory.
+ - Windows: Support for 64-bit executables.
+ - Windows: Support for cross compilation on Linux.
+Index: smartmontools-5.39.1+svn3124/os_linux.cpp
+===
+--- smartmontools-5.39.1+svn3124.orig/os_linux.cpp 2010-04-30 
19:35:35.0 +0200
 smartmontools-5.39.1+svn3124/os_linux.cpp  2010-12-23 11:05:12.103063859 
+0100
+@@ -196,6 +196,7 @@
+   smartctl --all --device=3ware,2 /dev/sda\n
+   smartctl --all --device=3ware,2 /dev/twe0\n
+   smartctl --all --device=3ware,2 /dev/twa0\n
++  smartctl --all --device=3ware,2 /dev/twl0\n
+   (Prints all SMART info for 3rd ATA disk on 3ware 
RAID controller)\n
+   smartctl --all --device=hpt,1/1/3 /dev/sda\n
+   (Prints all SMART info for the SATA disk attached 
to the 3rd PMPort\n
+@@ -1216,7 +1217,8 @@
+   enum escalade_type_t {
+ AMCC_3WARE_678K,
+ AMCC_3WARE_678K_CHAR,
+-AMCC_3WARE_9000_CHAR
++AMCC_3WARE_9000_CHAR,
++AMCC_3WARE_9700_CHAR
+   };
+ 
+   linux_escalade_device(smart_interface * intf, const char * dev_name,
+@@ -1389,12 +1391,17 @@
+ 
+ bool linux_escalade_device::open()
+ {
+-  if (m_escalade_type == AMCC_3WARE_9000_CHAR || m_escalade_type == 
AMCC_3WARE_678K_CHAR) {
++  if (m_escalade_type == AMCC_3WARE_9700_CHAR || m_escalade_type == 
AMCC_3WARE_9000_CHAR ||
++  m_escalade_type == AMCC_3WARE_678K_CHAR) {
+ // the device nodes for these controllers are dynamically assigned,
+ // so we need to check that they exist with the correct major
+ // numbers and if not, create them
+-const char * node   = (m_escalade_type == AMCC_3WARE_9000_CHAR ? twa
: twe);
+-const char * driver = (m_escalade_type == AMCC_3WARE_9000_CHAR ? 
3w-9xxx: 3w-);
++const char * node   = (m_escalade_type

Re: Bug#604016: Please support 3w-sas controllers

[Florian Weimer]

* Julien Cristau:

 On Mon, Nov 22, 2010 at 12:11:43 +0100, Giuseppe Iuculano wrote:

 Release Team,
 
 Would this be an acceptable change for a freeze exception?
 
 Yes (assuming it's properly tested).

Okay, I'll test an isolated backport tomorrow, using the hardware in
question.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/82wrnt3217@mid.bfk.de

Re: New PostgreSQL security/bug fix releases: 8.4.5, 8.3.12 [CVE-2010-3433]

[Florian Weimer]

* Martin Pitt:

 Please let me know how to proceeed with the security update.

Please upload the lenny part to security-master.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5g3nnef@mid.deneb.enyo.de

Re: possible xorg-server update in lenny?

[Florian Weimer]

* Julien Cristau:

 I've got a few changes queued up for xorg-server in lenny, and was
 wondering if it's worth uploading them at some point soonish.  I guess I
 could add the fix for CVE-2009-1573 (a minor bug in xvfb-run).

Yes, please do.  Thanks for taking care of these bugs.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874odlls8t@mid.deneb.enyo.de

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

[Florian Weimer]

* Philipp Kern:

 Florian,

 On 08/08/2010 11:21 AM, Florian Weimer wrote:
 Cool, it's based on OpenJDK 6b18.  However, we can't upload it as-is
 because the version number is greater than the one in testing.


 apart from the fact that this could of course be solved by an upload
 to t-p-u in the worst case, it's the case that packages from
 proposed-updates that are newer than testing at point release time are
 then copied into testing.

In this case, we don't want this behavior because the version
currently in testing offers more features than the version which is
about to be uploaded.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkwos3y6@mid.deneb.enyo.de

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

[Florian Weimer]

* Matthias Klose:

 Or does everybody see openjdk as an alibi for Debian to build things
 and then use the sun-java packages from non-free?

I know folks who use it in production, admittedly with compiler
excludes to work around some C2 bugs.

 For those who are interested in an openjdk-6 update for stable, I did
 prepare an update for some architectures at

   deb http://people.debian.org/~doko/archive stable/

Cool, it's based on OpenJDK 6b18.  However, we can't upload it as-is
because the version number is greater than the one in testing.

What can we do about the lack of mips support?

 I don't plan any updates for unstable/testing beyond 6b18.  6b20 is
 available in experimental, but disables the ARM assembler interpreter
 (which is 3-5x times faster than the plain zero build), and 6b20
 doesn't build anymore on sparc.

If upstream has ceased support for those architectures, should we
really release squeeze with them?  I'm pretty sure we we'll have to
upgrade to later versions at one point.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87eie9w2o6@mid.deneb.enyo.de

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Florian Weimer]

* Matthias Klose:

 On 21.11.2009 06:20, Florian Weimer wrote:
 * Steve Langasek:

 It's been suggested to me that it might help Debian move forward on this
 issue if I provide some background on why Canonical has chosen to not regard
 this issue as critical for Ubuntu.

 My personal impression is that Debian does not view this issue as
 critical, either.  Switching the GCC default hasn't happened for other
 reasons.

 Which are these reasons?

Uhm, aren't you more qualified than me to answer that?

I think we had established quite some time ago that the licensing
issue should not be considered a blocker.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: GCC 4.4 run-time license and non-GPLv3 compilers

[Florian Weimer]

* Steve Langasek:

 It's been suggested to me that it might help Debian move forward on this
 issue if I provide some background on why Canonical has chosen to not regard
 this issue as critical for Ubuntu.

My personal impression is that Debian does not view this issue as
critical, either.  Switching the GCC default hasn't happened for other
reasons.

We also ignored a similar issue in the GPLv1 case, but there is far
less code affected, of course.

The FSF has not contacted Canonical requesting a resolution,

The FSF generally licenses their code under GPL, version x or later,
so they are not affected by this at all.

Developers who license their code under the GPL, version 2, and no
later version, have a reason to complain.  The OpenSSL and KDE issues
are a precedents showing that we cannot rely on the system library
exception for linking to the run-time library here.  So the project's
position will be slightly inconsistent, but I think we can live with
that.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: open issues with the hppa port

[Florian Weimer]

* Carlos O'Donell:

 The nptl enabled hppa libc packages are in experimental.
 e.g.
 apt-get -t experimental install libc6

Out of curiosity, does this version support cross-process mutexes?


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bug#548126: pu: package opensaml2/2.0-2+lenny1

[Florian Weimer]

* Florian Weimer:

 Right.  Please upload opensaml2 first (after sending in a source
 debdiff for review), and then wait with uploading shibboleth-sp2 until
 we tell you it's okay to do so.

It's now possible to upload shibboleth-sp2 to security-master.  Thanks
for your assistance.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bug#548126: pu: package opensaml2/2.0-2+lenny1

[Florian Weimer]

* Faidon Liambotis:

 Florian Weimer wrote:
 Right.  Please upload opensaml2 first (after sending in a source
 debdiff for review), and then wait with uploading shibboleth-sp2 until
 we tell you it's okay to do so.

 OK, will do. How should we handle the fact that the newer xmltooling is
 breaking the old (as in, lenny) opensaml2/shibboleth-sp2?

We could theoretically add a Conflicts: to a new upload of xmltooling,
but this is unnecessary.  We don't do this for every bug that stems
from the interaction of two packages.

 I don't think it can be solved with regular dpkg constructs (xmltooling
 is already present in security), would just mentioning it in the DSA be
 alright?

apt-get upgrade will do the right thing, so it's sufficient to
mention the issue in general, I think.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bug#548126: pu: package opensaml2/2.0-2+lenny1

[Florian Weimer]

* Faidon Liambotis:

 Please note that this fix is in a header file in a function that's
 inlined, so after this update is accepted (assuming it's accepted),
 shibboleth-sp2 in stable will need to be rebuilt against the new version
 of opensaml2.  I understand that this can be done via the proposed-updates
 mechanism with a binary NMU.

 This problem still stands but it will have to be updated in security
 instead of proposed-updates. I guess a sourceful upload will be needed
 instead of a binNMU in this case?

Right.  Please upload opensaml2 first (after sending in a source
debdiff for review), and then wait with uploading shibboleth-sp2 until
we tell you it's okay to do so.

AFAICT, opensaml2 hasn't been uploaded to stable-proposed-updates yet,
so no action appears to be required from the release team.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: New PostgreSQL microreleases -- -updates or -security?

[Florian Weimer]

* Martin Pitt:

 My gut feeling is that it should go through s-p-u (Debian), and
 -proposed (Ubuntu) and be copied to -updates after some time of
 testing.

After conferring with Tom Lane from upstream, I lean towards releasing
a DSA.

Please contact security@ when you've got packages which you consider
ready for uplad.  Thanks!


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Status of Haskell in unstable/testing

[Florian Weimer]

* Luk Claes:

 The most important issues seems to be that ghc6 FTBFS on ia64 [1].

Is ia64 a registerized build (if this GHC-ism is still relevant)?


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Status of Haskell in unstable/testing

[Florian Weimer]

* Luk Claes:

 Florian Weimer wrote:
 * Luk Claes:
 
 The most important issues seems to be that ghc6 FTBFS on ia64 [1].
 
 Is ia64 a registerized build (if this GHC-ism is still relevant)?

 You apparently did not include the footnote. Though if you want to ask
 if it has a buildbot: unfortunately not.

Sorry, I tried to make clear that it's a GHC-ism.  There used to be a
Perl script which was run on the assembler code created by GCC, using
markers injected through asm directives to guide optimizations.
Obivously, this was rather brittle.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Advice; want to upload new onak package to stable

[Florian Weimer]

* Jonathan McDowell:

 I'd like to upload a new onak package to stable to fix #520117 by
 rebuilding against db4.5 instead of db4.6 - I'm hitting what seems to be
 #510270 in db4.6.

Shouldn't this be fixed in db4.6 instead?


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

BIND 1:9.5.1.dfsg.P2-1 for stable

[Florian Weimer]

Hi,

I'd like to upload 1:9.5.1.dfsg.P2-1 to stable-proposed-updates (as
1:9.5.1.dfsg.P2-1+lenny1) to fix a bug in DLV processing.  We can then
point users to this version if they use dlv.isc.org and experience
resolution failures for .gov:

https://lists.dns-oarc.net/pipermail/dns-operations/2009-April/003736.html

Florian


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: BIND 1:9.5.1.dfsg.P2-1 for stable

[Florian Weimer]

* Florian Weimer:

 Hi,

 I'd like to upload 1:9.5.1.dfsg.P2-1 to stable-proposed-updates (as
 1:9.5.1.dfsg.P2-1+lenny1) to fix a bug in DLV processing.  We can then
 point users to this version if they use dlv.isc.org and experience
 resolution failures for .gov:

 https://lists.dns-oarc.net/pipermail/dns-operations/2009-April/003736.html

Sorry, this is the correct URL:

https://lists.dns-oarc.net/pipermail/dns-operations/2009-March/003710.html


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Request of authorisation for an upload of Snort in stable to fix 503992

[Florian Weimer]

* Luk Claes:

 I would like to make an upload to stable to fix bug 503992 of Snort. Basicly,
 this bug was introduced with the patch for a security vulnerability but
 introduced a sigsegv due to an improper call to a function. This error kills
 the Snort IDS as soon as it receives fragmented traffic which. In some
 systems (such as systems behind an ADSL) this seems to happen frequently
 enough.

 Any reason why this regression caused by a security upload, should not
 be fixed by a security upload (I've put the Security Team in Cc)?

It's probably a security bug on its own, so it probably should go
through the DSA process, even though the bug was introduced through
t-p-u before the lenny release.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bug#503992: Request of authorisation for an upload of Snort in stable to fix 503992

[Florian Weimer]

* Javier Fernández-Sanguino Peña:

 It's probably a security bug on its own, so it probably should go
 through the DSA process, even though the bug was introduced through
 t-p-u before the lenny release.

 Since Neil answered already I uploaded the packages to stable using the patch
 I sent. If you want them to go through the DSA process I guess the security
 team should do the upload themselves right?

I don't think it's worth the effort because the point release is not
too far away, right?

Anyway, thanks for addressing this issue.


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Whoos with GnuTLS and md5-signed certificates

[Florian Weimer]

* Florian Weimer:

 Would those who have an interest in this topic please test the patch
 in

 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=97;bug=514807;mbox=yes

 and report if it improves things for them?  Thanks.

For the record, it's very likely that we are soon to release updates
with the patch applied.  We will not change the MD5 behavior because
it is not clear to me that it is necessary.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Whoos with GnuTLS and md5-signed certificates

[Florian Weimer]

Would those who have an interest in this topic please test the patch
in

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=97;bug=514807;mbox=yes

and report if it improves things for them?  Thanks.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Whoos with GnuTLS and md5-signed certificates

[Florian Weimer]

* Bastian Blank:

 GnuTLS stopped accepting MD5 as a proper signature type for certificates
 just two weeks before the release. While I don't question the decision
 themself, MD5 is broken since 4 years, I question the timing.

GNUTLS has rejected RSA-MD5 signatures in X.509 certificate chains
since version 1.2.9.

 Yesterday several people started to complain that they could not longer
 connect to their ldap servers, many of them using pam-ldap and nss-ldap.
 A quick look showed certificates in the chain which was signed with MD5.

Are you sure this isn't #514807?


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Pre-approval for apt 0.7.21: Valid-Until feature and proxy changes

[Florian Weimer]

* Moritz Muehlenhoff:

 And there is also the option of including it in the first point release,
 after a month or two of testing in unstable.

 Since the replay attack isn't exactly grave, it could just as well be added
 into 5.0.1 oder 5.0.2 once it has gotten some testing.

And if Valid-Until is only checked against the real-time clock, the
attacker can still feed bad data over NTP, so it's not even a complete
defense. 8-(


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Pre-approval for apt 0.7.21: Valid-Until feature and proxy changes

[Florian Weimer]

* Eugene V. Lyubimkin:

 Florian Weimer wrote:
 And if Valid-Until is only checked against the real-time clock, the
 attacker can still feed bad data over NTP, so it's not even a complete
 defense. 8-(

 However, it seems there is no better solution, or is there?

A counter in the style of a Lamport clock should work, or checking
that the Valid-Until header does not recede in time.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Pre-approval for shadow 1:4.1.1-6

[Florian Weimer]

* Nicolas François:

 Release Managers, Security Team:
 Do you want 505071 to be fixed also for Lenny?

Do you mean etch instead of lenny?

We'd probably release a DSA once there's a patch which has some track
record, but as far as I can tell, the issue has not been fully
analyzed yet.  You guard against a symlink attack, but you don't seem
to ensure that the TTY name retrieved from the utmp file is correct in
the first place.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: freeze exception for cacao-oj6

[Florian Weimer]

* Matthias Klose:

  - s390: rebuilt by hand on raptor/unstable without problems.
Bastian pointed to #479952 as a possible reason. would it
be possible to do a test-rebuild on the machine which is
used security updates?

I think we can apply a real security patch to all the Sun-based JDKs and
see how it works out.  I'll ask the (testing) security team about it.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: freeze exception for cacao-oj6

[Florian Weimer]

* Matthias Klose:

 Well, you know that there is a T2000 available and if the security team
 needs a faster buildd they have to ask.

 the estimate is wrong.

I what sense?  I quoted the actual build time on lebrun.  Is spontini
really faster than that?

 the openjdk-6 package runs the testsuite. if the security team prefers
 shorter build times, then the testuite can be disabled in security
 uploads.

Uhm, okay.

 the testsuite is not run in the cacao-oj6 package.

And build times are reasonably fast.

 if the security team has the opportunity to use a faster machine,
 please consider using it.

The security team doesn't run wanna-build for the security buildd
network, or the security buildds themselves.  We prefer stable *and*
reasonably fast buildds, of course.  But we aren't involved in their
operation.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: freeze exception for cacao-oj6

[Florian Weimer]

* Luk Claes:

 Matthias Klose wrote:
 proposing a freeze exception for cacao-oj6 for testing. cacao-oj6 is a
 copy of the openjdk-6 package with the cacao sources
 included. Compared to openjdk-6 on architectures without the Hotspot
 JIT support, cacao-oj6 (including a JIT) is a much faster JVM on the
 architectures where it does build (powerpc, s390, armel for
 now). Discussed this at Debconf with some people. I was told to get
 agreement with debian-security about the maintainability (because of
 the duplicate sources). See #495256 as well.

 What was the conclusion of the discussion with the Security Team?

I don't recall a discussion.  Anyway, I want to see a -2 first, to see
if it can actually be auto-built on all release architectures, and what
the timings are.

A security update for the OpenJDK 6 source base will require more than
60 hours of armel build time, and more than two weeks[1] on sparc for
openjdk-6 alone (don't know cocoa-oj6 yet).  Anything longer than half a
day is very difficult for us.

[1] Estimate based on a built time of 205 hours on lebrun, which has got
a 750 MHz CPU.  spontini is a U60, which is probably only half as
fast.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenJDK for lenny

[Florian Weimer]

* Matthias Klose:

 So, we are late with OpenJDK for lenny. I still think lenny would
 benefit from having OpenJDK. I'm proposing the following steps,
 realizing that not all of them probably can be realized.

Is there upstream security support for OpenJDK 6?  I'm asking because
the DLJ stuff used to lag quite a bit.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [alpha, hppa] GCC-4.3 as the default compilers for lenny?

[Florian Weimer]

* Pierre Habouzit:

 Isn't it risky for partial upgrades from etch ? Shouldn't we wait for
 lenny+1 to revert this ?

   I second that, please don't revert the patch until lenny+1. FWIW I
 believe the release team as a whole wanted the patch to be kept as well,
 but I'll let the other members correct me if I'm wrong.

What about fixing the etch kernel?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

mipsel packages file borken

[Florian Weimer]

$ wget 
http://ftp.us.debian.org/debian/dists/etch/main/binary-mipsel/Packages.bz2
$ bzcat Packages.bz2 | grep '^[^ ][^:]*$'
133270:ides a wizard that helps you
133274:eror is the file manager for the K Desktop Environment.
$ 

Something has been garbled.  Other architectures do not suffer from this
problem.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-db-devel] Bin-NMUs for radiusd-livingston, libtabe; db4.5

[Florian Weimer]

* Steve Langasek:

 If you can tell me how to do this without downloading dozens of MB of
 data, I'll do it.

 Well, it would've been easier if the addition of db4.5 symbol versions had
 been accompanied by a shlibs bump,

Yeah, but this was a bug I tried to fix. 8-/

 but something like this running against the full mirror on merkel
 should do the trick:

Ah, thanks, saved for the future.

 BinNMUs are scheduled now.  The final list of packages is dhelp, nmh,
 radiusd-livingston, webalizer, and webdruid.

Thanks a lot!

  In a related issue, testing migration for db4.5 is prevented by the
  removal of Java packages on hppa in 4.5.20-8.  This probably needs some
  kind of manual hint.

  For binary removals ask the ftp-team.

 Is this correct?

 Yes.

Uh-oh.  In this case, it's probably overkill to disable Java locally as
soon as it breaks on a fringe architecture because it involves too much
work down the road.  Fixing the actual breakage is likely easier.  In
this particular case, GCJ on hppa is able to build db4.5 again, so no
more manual work should be needed.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-db-devel] Bin-NMUs for radiusd-livingston, libtabe; db4.5

[Florian Weimer]

* Bastian Blank:

 On Mon, Oct 15, 2007 at 03:11:20PM +0200, Florian Weimer wrote:
 Would you please schedule bin-NMUs for radiusd-livingston and libtabe on
 all architectures?
 
 (There might be more packages affected on other architectures, but I
 can't easily search for them.)

 You should provide a list of all packages which does this, not only the
 two.

If you can tell me how to do this without downloading dozens of MB of
data, I'll do it.

 In a related issue, testing migration for db4.5 is prevented by the
 removal of Java packages on hppa in 4.5.20-8.  This probably needs some
 kind of manual hint.

 For binary removals ask the ftp-team.

Is this correct?

 The changelog does not really list a reason for the hppa java removal.

AFAIK, these changes are made upon request from the Java toolchain
maintainers, the Berkeley DB team hasn't got much choice here.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Please migrate db4.3 4.3.29-10 to testing

[Florian Weimer]

db4.3 4.3.29-9 went into testing despite an RC bug (#442297).  The bug
is fixed in version 4.3.29-10.  Could you please bump the urgency so
that this rectified soon?  Thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Please migrate db4.3 4.3.29-10 to testing

[Florian Weimer]

* Steve Langasek:

 The bug is fixed in version 4.3.29-10.  Could you please bump the urgency
 so that this rectified soon?  Thanks.

 Bumping the urgency won't change the fact that the package failed to build
 on the hppa autobuilder.

This has been an going problem since version 4.3.29-1 at least.  The
build only passes when the testsuite runs into a test failure which is
ignored by the build environment.

I'll need to check what we can do about this.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: NMU for rlwrap to etch-proposed-updates (for etch r1)

[Florian Weimer]

* Steve Langasek:

 On Fri, May 25, 2007 at 07:30:36PM +0200, Florian Weimer wrote:
 I'd like to do a sourceful (i.e. non-binary-only) NMU of rlwrap for
 etch r1, so that the package gets rebuilt on all architectures.
 Queing binary NMUs is apparently not enough to fix this issue.

 Why not?  Were binNMUs of rlwrap requested?  I don't see that there
 are currently rlwrap binNMUs scheduled for stable, nor do I find a
 request for such in my inbox.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410978;msg=15

Or has this changed since the release?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

NMU for rlwrap to etch-proposed-updates (for etch r1)

[Florian Weimer]

I'd like to do a sourceful (i.e. non-binary-only) NMU of rlwrap for
etch r1, so that the package gets rebuilt on all architectures.
Queing binary NMUs is apparently not enough to fix this issue.

Would that be acceptable?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Please unblock debsecan 0.4.7

[Florian Weimer]

Compared to the version in testing, debsecan 0.4.7 offers translation
updates and the following bug fix.

TIA,
Florian

Fri Mar  2 22:00:56 CET 2007  Florian Weimer [EMAIL PROTECTED]
  * Migrate /var/lib/debsecan away from root permissions unconditionally.

diff -rN -u old-debian/debian/debsecan.postinst 
new-debian/debian/debsecan.postinst
--- old-debian/debian/debsecan.postinst 2007-03-15 13:48:46.0 +0100
+++ new-debian/debian/debsecan.postinst 2007-03-15 13:48:46.0 +0100
@@ -6,10 +6,15 @@

 case $1 in
 configure)
-   # fix permissions on upgrade, will also run for fresh
-   # installations.
+   # If the directory is owned by root, change ownership.  This
+   # happens for fresh installations, and re-installations after
+   # removal (and purge, of course).
+   find /var/lib/debsecan -maxdepth 0 -user root | while read dir ; do
+   chown daemon:daemon $dir
+   done
+
+# Fix permissions on upgrade from ancient versions.
if dpkg --compare-versions $2 '' 0.2.1 ; then
-   chown daemon:daemon /var/lib/debsecan
if test -e /var/lib/debsecan/history ; then
chown daemon:daemon /var/lib/debsecan/history
fi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#408929: Fwd: Processed: Re: Bug#408929: emacs21: crash on spam

[Florian Weimer]

* Moritz Muehlenhoff:

 glibc 2.3.4 introduced more secure heap management, which renders several
 code injection attacks moot.

I think these additional checks have already been bypassed.  Shall I
dig up a reference?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Unblock or remove xml2rfc

[Florian Weimer]

The IETF Secretariat will soon reject Internet-Drafts formatted using
the etch's version of xml2rfc (because of an outdated boilerplate).
The new upstream version in unstable should generate acceptable
drafts.  Unfortunately, the diff is quite large.  If it's not possible
to accept the new upstream version into etch, please file an RC bug
and remove the package from testing.

Thanks!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

BIND 8 deprecation for the release notes

[Florian Weimer]

I recommend to add a note urging people to switch to BIND 9 (possibly
mentioning check-names ignore, which is one of the larger hurdles
IIRC).

The main reason is this bug:

CVE-2006-0527 (BIND 4 (BIND4) and BIND 8 (BIND8), if used as a target 
forwarder, ...)
- bind 1:8.4.7-1 (low)
[sarge] - bind no-dsa (Architectual limitatiom, upgrade to BIND 9 as 
a a fix)
NOTE: BIND 8 is unsuitable for forwarder use because of its
NOTE: architecture.  Upgrade to BIND 9 as a fix.
NOTE: This was fixed in sid by documenting it as an unfixable design 
limitation


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Solving the linux-2.6 firmware issue

[Florian Weimer]

* Bastian Blank:

 Not possible without another large round of testing. Our infrastracture
 currently expects that the upstream part of the version remains
 the same through the whole cycle. This information is for example used
 to find all patches.

Uhm, why can't you do a simple full upload just once, manually?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Solving the linux-2.6 firmware issue

[Florian Weimer]

* Frederik Schueler:

 As we need to upload a new orig.tar.gz file, we need to rename the
 source package.

Huh?  Non sequitur.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: mailman 2.1.5-8sarge3: screwup between security and maintainer upload

[Florian Weimer]

* Martin Schulze:

 Imho, it's more useful to upload 2.1.5-8sarge4 and only bump the
 version number to get the new version built for all architectures into
 the archive.

While you are at it, you could also include this patch:

Revision: 8001
  http://svn.sourceforge.net/mailman/?rev=8001view=rev
Author:   bwarsaw
Date: 2006-08-30 07:54:22 -0700 (Wed, 30 Aug 2006)

Log Message:
---
CVE-2006-3636.  Fixes for various cross-site scripting issues.  Discovery by
Moritz Naumann and most of the repair work done by Mark Sapiro (with some
additional work by Barry).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Preparing the next Release

[Florian Weimer]

* Martin Schulze:

 When there is no cups for amd64 in the release, it does not matter
 whether it FTBFS on amd64 or not, for example.

I believe that such FTBFS bugs are already deemed important; they
are not release-critical.  A lot of porters who file FTBFS bugs
disagree, but this doesn't make them right.

 While I would love to have the exact set of packages on all
 architectures, I need to accept the fact that on some architectures
 some packages just don't work or cause an FTBFS we are unable to fix
 in time for the release.

Some of these bugs will be discovered only after the release, anyway.

 This is a bit exagerated, but I hope you'll get an idea of what I was
 trying to express.  When the data los *can* happen in only certain
 quite uncommon circumstances and the rest of the system and of the
 package works fine, I'm not too sure we should delay the release to
 get this problem fixed before.

Maintainers tend to decrease the severity of the corresponding bug
reports below RC level on their own.  I believe we generally do this
for web browsers, for example, which seems to be the right thing to
do.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Secure APT Key Management

[Florian Weimer]

* Martin Schulze:

 I'd really love to see this feature properly implemented.

The only approach which is known to work is static keys for stable
releases and stable security updates.  The keys can be stored off-line
or on-line, at the discretion of the respective teams.

So far, we have botched all yearly key rollovers, and there is zero
evidence that we'll get the first one that reallly matters right.
Unfortunately, the key rollover approach is generally assumed to be
required to achieve a decent level of security and strongly preferred
over the alternatives.  Needless to say, I very strongly disagree with
that position.

(IIRC, -release is not a discussion list, so details such be discussed
elsewhere.)

From a release engineering view, the last possible date at which APT
key material can be included in d-i would be interesting, I guess.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Time to kick xdelta out of testing?

[Florian Weimer]

* Russ Allbery:

 Is this bug fixed in xdelta 2.0?

xdelta 2 is a completely different beast.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: libstdc++ configuratrion

[Florian Weimer]

* Matthias Klose:

 Does it change the internal representation of std::string, or some
 other template instantiation provided by libstdc++?

 I don't see a change to the internal representation of std::string,
 I'm forwarding this upstream.

std::string seems to be fine because the instance is declared extern,
preventing most inlining, and the allocator is hidden using the PIMPL
idiom.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: current blockers?

[Florian Weimer]

* Nathanael Nerode:

 * removal of non-free docs etc. from all packages

IIRC, the release goal is to release without GNU FDL documentation
only, not to remove all non-free documentation.  At least I'm not
aware of a coordinated effort in that direction.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: libstdc++ configuratrion

[Florian Weimer]

* Matthias Klose:

 The change does not have an effect on symbols exported from
 libstdc++, but it does have an effect on symbols exported by
 libraries which use containers (using an allocator) from the
 template headers.

Does it change the internal representation of std::string, or some
other template instantiation provided by libstdc++?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: testing security status (post kde)

[Florian Weimer]

* Steve Langasek:

 Heh.  Would it be worth posting summaries of the unfixed RC security bugs
 somewhere from time to time, to try to get more people involved with NMUing
 them?  Or are most of these not RC security bugs at this point?

There is http://idssi.enyo.de/tracker/status/release/unstable (based
on the testing team data), which should mostly up to date.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: bug 284925

[Florian Weimer]

* Thomas Bushnell:

 What is expected of me with respect to bug 284925?  I would like to
 close it; a DSA was given for the version in stable, it refers to
 woody only, etc, something like that.  I don't understand the details,
 but I'd like to close it.  What should I do?

You should acknowledge the NMU of 1.9.14-17.1 and make sure that these
changes are applied.  Ah, you did that, but since the bug was filed
against two packages, it didn't have the intended effect.

The changelog mentions only CAN-2004-1026.  Maybe you could check that
CAN-2004-1025 is fixed as well, and mention it in the changelog?
I'll see if I can find a copy of Red Hat's SRPM.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Statement(s) on libssl situation desired

[Florian Weimer]

* Nathanael Nerode:

 Note the following apparent facts:
 * libssl0.9.7 and libssl0.9.8, if linked in the same binary, will cause 
 unpredictable failure due to symbol conflicts.
 * This could be fixed if libssl0.9.8 had versioned symbols, which it doesn't 
 yet.

Are you sure?  I think it's not too uncommon that other libraries
which depend on OpenSSL provide access to some underlying SSL
functionality, directly exposing public SSL interfaces.  The dependent
library typically does not provide a versioned ABI.  Now take two such
dependent libaries, and you might still need some kind of transition.

However, the scenarios in which a versioned OpenSSL library does the
right thing seems to be a strict superset of the non-versioned case,
so it might still be a win.  It doesn't seem to be the whole story,
though.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Resignation as Debian Release Manager

[Florian Weimer]

* Branden Robinson:

 On Fri, Sep 23, 2005 at 12:10:00AM +0100, Colin Watson wrote:
 I hereby tender my resignation as Debian Release Manager.

 Thanks for your outstanding service, Colin.  Reinventing the team
 mid-release was not easy, but you and Steve didn't flinch from it and did a
 great job.

Yes, thanks indeed.

Branden, would you please document publicly the delegation you made in
this context (and Colin alluded to)?

I think we already have enough trouble with non-transparent
delegations which are disputed by the delegates. 8-) (Not that I think
it would be a problem in this case.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: wanna-build only knows about older versions?

[Florian Weimer]

* Steve Langasek:

 Of course security support is essential for released architectures,

I don't think this is the case.  Apparently, we have successfully
without security support, therefore it cannot be essential.

It's desirable, sure, but essential?  Certainly not.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: gnupg, t-prot and the release

[Florian Weimer]

* Gerfried Fuchs:

  I was told that gnupg might be updated for sarge with the version from
 unstable. Please be aware that the gnupg version has changed some of its
 locale strings on which t-prot depends for doing its work.

Huh?  In this case, t-prot is fundamentally borken.  It should use
--status-fd (or GnuPG's co-processing mode).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Please remove xml2rfc from sarge

[Florian Weimer]

severity 303131 serious
thanks

* Steve Langasek:

 Sure, tagged for removal.

Thanks.  Is it possible that the removal is deferred by the freeze?
madison on merkel says that the package is still in testing.

 (I can bump #303131 to severity serious if this helps.  IIRC, due to
 synchronization issues, I should wait until tomorrow with that.)

 What synchronization issues are those?

I thought that there was some race condition in the testing handling
scripts, but it's probably irrelevant in this case.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Please remove xml2rfc from sarge

[Florian Weimer]

In effect, the IETF Secretariat requires that very specific versions
of xml2rfc are used when you submit Internet-Drafts, which include the
prescribed boilerplate texts in the generated documents.  I expect
that the required boilerplates change again in the short term (mainly
because of their sexist language).  This means that it's likely that
the xml2rfc package will be outdated and mostly unusable shortly after
the sarge release.

Although I've upload a new upstream version 1.29, which will align the
Debian package with the current requirements stated by the IETF
Secretariat, I'd like to ask you to remove the xml2rfc packages from
the sarge release nevertheless.  (I can bump #303131 to severity
serious if this helps.  IIRC, due to synchronization issues, I should
wait until tomorrow with that.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-db-devel] Re: libdb*, mutex and threading

[Florian Weimer]

* Clint Adams:

   db4.2:
   #232305: libdb4.2: Hangs on SMP (HyperThreaded P4) system using slapd 
   2.1.25-1
 
  There doesn't seem to be a fix for this?  Or did I miss
  something?
 
 AFAICS, this is fixed with changing configure to never link to pthread,
 and not using LD_ASSUME_KERNEL.

 When is it linking to pthread?

When it detects that POSIX mutexes can cross address spaces, I
believe.  If this logic has been overridden (for example, by setting
db_cv_mutex, or by patching configure.ac---which is a must for Debian,
to support 2.4 kernels without NPTL), linking against a threading
library should not occur.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Suggestion: Release sarge without security support

[Florian Weimer]

* Laszlo Boszormenyi:

 Why can't we treat security support like a broken package, and remove
 it if it isn't fixed by its maintainers?

  Because you miss the point. You remove the package from the archive,
 and not from the users' system. So the users would be still vulnerable,
 and everyone would hate Debian.

I'm not suggesting to carry out security support by removing broken
packages (that's almost impossible after a release, as you correctly
noted).  I'm suggesting to drop security support as a whole, like a
package with a release-critical bug is removed from the release if it
isn be fixed by the maintainers (or someone else who has the
necessarily knowledge and authorization to implement a fix).

No security support means exactly what it says: doing nothing, not
even removing affected packages.

Suggestion: Release sarge without security support

[Florian Weimer]

Hi,

it seems that the lack of security buildds is the biggest obstacle to
the sarge release.

Why can't we treat security support like a broken package, and remove
it if it isn't fixed by its maintainers?  I hate this approach as much
as the next guy, but it might be the only way to make progress with
the release, for the foreseeable future.  Security support could be
added in a point release, completely transparently to Debian users,
when the resources become available.

Florian

Re: status of non-US

[Florian Weimer]

* Martin Schulze:

 Florian Weimer wrote:
 * Andreas Barth:
 
  So, the only thing left now is pgp5i in non-US/non-free (and AFAICS this
  can't go to non-free).
 
 What's the security patching status of pgp5i?

 What are you referring to?

I've checked in the meantime.  The RNG issue has been been fixed, but
the UID issues (see http://www.bluering.nl/pgp/useridbug.txt, for
example) are not addressed.  I haven't tested PGP 5, but the
vulnerability is definitely present in other versions, even back to
2.6.3in, so it's unlikely that pgp5i is magically unaffected.

Re: status of non-US

[Florian Weimer]

* Andreas Barth:

 So, the only thing left now is pgp5i in non-US/non-free (and AFAICS this
 can't go to non-free).

What's the security patching status of pgp5i?

Re: wget for sarge update

[Florian Weimer]

* Colin Watson:

 On Sat, Oct 02, 2004 at 02:59:13PM +0200, Noèl Köthe wrote:
 wget = 1.9.1-4 (which is in sarge and frozen) had a security problem
 (#261755) which is fixed in -6 and -7 (right now in incoming). -5 had
 the first fixing patch but was not multibyte aware (#271931).
 Jan Minar jjminar fastmail.fm wrote the fixing patches (Thanks!).
 Upstream author doesn't respond to this and other things/mails since
 weeks so right now he is MIA.:(

   mdz Kamion: I think it's silly
   mdz Jan Minar has filed a bunch of similar bugs
   mdz I'm waiting for the one against cat(1)
   mdz where it will allow arbitrary characters to be displayed on the 
 terminal

 Is this really a security issue?

I don't think programs should print data received from untrusted
sources without properly quoting control characters (or replacing
them).  However, I don't think this should get the honor of a
last-minute fix, especially if it hasn't been approved by upstream.

Does the patch change a common code path?  (The potential memory leak
I criticized earlier apparently has been fixed.)