Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

2021-03-03 Thread Florian Weimer
* Elana Hashman:

> You and the original report mention "tooling issues". Can you please
> provide some examples of tools that do not currently support working
> with compressed symbols and the resulting effects on developer workflow?

dwz still can't process compressed debuginfo sections, I think.  It's
the reason why Fedora uncompresses all debuginfo sections.

It's also not clear to me which compression approach is to be used,
the GNU one or the ELF standard one.  I expect support for GNU to be a
bit more widespread in our world because it's been around for a bit
longer.



Bug#971515: Request for security team input on kubernetes TC bug

2020-11-17 Thread Florian Weimer
* Moritz Mühlenhoff:

> On Sun, Nov 08, 2020 at 10:49:31PM +0100, Florian Weimer wrote:
>> * Moritz Mühlenhoff:
>> 
>> > * Follow a scheme similar to Firefox ESR where in case of a security
>> >   the update either happens to the latest minor release of
>> >   the current branch or if that has stopped, happens to the next
>> >   major release. To map this to specific k8s releases: Let's assume 
>> > bullseye
>> >   were already stable and would ship 19.3. In three months a security issue
>> >   arises which is severe enough to warrant an update and we ship 19.5
>> >   in a DSA. Fast forward 6 months and 19.x is EOLed, but some severe
>> >   security issue needs to be fixed; then the bullseye update would move
>> >   to 20.1 or so. That sounds unusual for a Debian release, but it's
>> >   the status quo for _any_ Kubernetes user after all (whether deployed
>> >   on premises or at some "cloud vendor").
>> 
>> Another thing to consider: Kubernetes rebases will likely require Go
>> rebases, if I read this table correctly:
>> 
>> <https://github.com/kubernetes/community/blob/master/contributors/devel/development.md#go>
>
> I can't tell how strict these requirements are in practice.

Let's just say that some Kubernetes developers are very eager to get
their hands on the most recent Go toolchain even if there are
practical issues with choices in the run-time library, such as the
changes to certification validation.  Not sure if anyone would want to
suffer these toolchain rebases if there was a clean way around them. 8-)

> It's similar to Firefox requiring more recent versions of rustc and
> golang packages are co-installable, so when it comes to that, shipping
> a new golang-x.y package might also be an option.

I see.

>> Since Go has a bit of spotty history in terms of kernel backwards
>> compatibility, this could cause further challenges.
>
> Do you have a concrete example of such a change? I see that 1.14 is
> available in backports, so this seems to work out so far.

I think that's it: <https://github.com/golang/go/issues/37436>
If I recall correctly, there was a kernel version check (!) that
managed to reject kernels which did not have the bug.  And combined
with the workaround failing, this led to non-functional programs.



Bug#971515: Request for security team input on kubernetes TC bug

2020-11-08 Thread Florian Weimer
* Moritz Mühlenhoff:

> * Follow a scheme similar to Firefox ESR where in case of a security
>   the update either happens to the latest minor release of
>   the current branch or if that has stopped, happens to the next
>   major release. To map this to specific k8s releases: Let's assume bullseye
>   were already stable and would ship 19.3. In three months a security issue
>   arises which is severe enough to warrant an update and we ship 19.5
>   in a DSA. Fast forward 6 months and 19.x is EOLed, but some severe
>   security issue needs to be fixed; then the bullseye update would move
>   to 20.1 or so. That sounds unusual for a Debian release, but it's
>   the status quo for _any_ Kubernetes user after all (whether deployed
>   on premises or at some "cloud vendor").

Another thing to consider: Kubernetes rebases will likely require Go
rebases, if I read this table correctly:



Since Go has a bit of spotty history in terms of kernel backwards
compatibility, this could cause further challenges.



Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)

2016-10-18 Thread Florian Weimer
* Adrian Bunk:

> On Wed, Oct 05, 2016 at 10:00:53AM -0400, Sam Hartman wrote:
>>...
>> I think it's clear that the TC believes that this package is not DFSG
>> free.
>> I think it's clear that the TC believes perl would be better if the
>> situation was improved.
>> I thought it was clear we believed perl had a DFSG issue, although IRC
>> discussion today makes that less clear.
>> I don't think the value of having the TC formally say any of those
>> specific things is very high.
>>...
>
> Please describe the relevant differences between browserified javascript 
> and perl that make the TC believe that the former has a DFSG issue but 
> the latter probably has not, in a way that I can deduct what the TC 
> would believe regarding the similiar problem related to SQLite.

Configure in Perl is a build tool, and appears amenable to manual
patching.

Browserified Javascript is hardly human-editable, and it is shipped as
part of built packages.  These scripts need regular maintenance, and
patching what is in Debian directly is too cumbersome.  I can't quite
understand why there is any debate that shipping these artifacts
without sources which are built at build time is in any way desirable.
If we don't build from source, how we are supposed to fix bugs?

(Pre-compiled C files from Vala sources have the same issue, I think.
Ocaml's bootstrapping from pre-compiled bytecode is slightly
different.)



Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-31 Thread Florian Weimer
* Theodore Ts'o:

 The most basic is the idea that whether you can control (via shell
 scrpit fragments) whether or not a service should start at all, and
 what options or environments should be enabled by pasing some file.

Curiously, a lot of system administrators do not do this correctly
using sysvinit, causing system daemons to start unexpectedly after
installing package updates.

I hope that a new init system will finally allow us to have something
like chkconfig (not the best name in the world, I admit) that works
reliably.


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



Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian

2009-08-28 Thread Florian Weimer
* Steve Langasek:

 On Tue, Feb 03, 2009 at 08:32:20AM +, Gerrit Pape wrote:
  2.1 I'd suggest not to change that, it's a good compromise between
  performance and reliability.

   2.1. Bounce message contents are not crash-proof.

   Qmail does not value the contents of a bounce message. Dan documents this
   in a subordinate clause of his qmail reliability FAQ. That means: if your
   qmail is bouncing mail and at the same time, your system crashes, the
   bounce mail contents may be corrupt or incomplete.

 This sounds like data loss, which is normally considered a grave bug per
 http://www.debian.org/Bugs/Developer.  Do people disagree that this is a
 grave bug?

Yes.  Most of our MTAs deliberately truncate bounce messages.

And arguing with RFC 3461 is a bit problematic because our default MTA
doesn't implement that RFC.


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



Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian

2009-01-11 Thread Florian Weimer
* Kalle Kivimaa:

 Steve Langasek vor...@debian.org writes:
 Can you expand here on the consequences of ignoring RFC1894?  I'm aware that
 qmail delivery failure mails look different (and, I might argue,
 gratuitously so) than those of other mail systems, but does this cause
 interoperability problems for other Internet users?

 RFC1894 ignorance produces at least these problems for
 interoperability in Internet:

Our default MTA does not implement RFC 1894.  Given that, I think it's
wrong to criticize other MTAs for lack of support.

(Your points are correct, though.)


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



Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish

2008-01-28 Thread Florian Weimer
* Ian Jackson:

 On the other hand, the behaviour of a round robin honouring host
 depends on the frequency of DNS retries, past network topology
 history, etc., in a way that may be difficult to predict.

Sure, but round-robin behavior is not tied to the bit pattern of
addresses, so it's less likely that there is a systematic bias.


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



Re: Bug#438179: RFC3484 rule 9 active again in glibc 2.7-5.

2008-01-23 Thread Florian Weimer
* Kurt Roeckx:

 For those that didn't notice this yet, 2.7-5 reverted the change of
 2.7-4.  So testing and unstable uses rule 9 again.

I'm confused.  Was this intentional?


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



Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)

2007-12-21 Thread Florian Weimer
* Kurt Roeckx:

 On Sun, Dec 02, 2007 at 10:10:38PM +, Ian Jackson wrote:
 Florian Weimer writes (Re: Bug#412976 repoened - reassign tech-ctte 
 (mixmaster /etc/default/*)):
  Really?  Won't upgrades re-enable disabled services if update-rc.d is
  used?
 
 Only if you delete _all_ of the links.  If you leave the K links in
 the shutdown and reboot runlevels, they will not be put back.
 
 This ought to be documented somewhere ...

 It is documented in the update-rc.d manpage:

Interesting, thanks.

The manpage also says:

| System administrators are not encouraged to use update-rc.d to manage
| runlevels.

My experience with update-rc.d has been mixed at best.  Removing the S
links manually is probably the better approach (instead of accidentally
removing the K links as well, risking reactivation).


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



Re: Package-created usernames

2007-12-21 Thread Florian Weimer
* Bdale Garbee:

 The second is whether it's acceptable for a Debian package to
 *require* a specific username.

There are a couple of setuid binaries which might have problems
switching to a more flexible scheme.  I fear such a requirement might
actually reduce overall security.


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



Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)

2007-12-02 Thread Florian Weimer
* Marc Haber:

 On Sat, Dec 01, 2007 at 07:34:58PM +0200, Jari Aalto wrote:
 From Admin's point of view dealing with symlinks is much more
 uncomfortable to control the initial start/stop status.

 If one is not comfortable with a sysvinit scheme, one should not be
 adminning a Debian system. Alternatives (such as file-rc) are
 available, and while update-rc.d is strictly speaking only geared to
 be used from maintainer scripts, it can also be used as a tool for the
 local admin.

Really?  Won't upgrades re-enable disabled services if update-rc.d is
used?


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



Re: getaddrinfo() behaviour

2007-10-02 Thread Florian Weimer
* Anthony Towns:

 Updating the proposed standard has not been tried.

Just to give you an idea of the time scale involved: moving RFC 3484
to HISTORIC (which is the most likely result, at least for the Rule 9
part) will take at least a year.


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



Re: A comment about RFC 3484 address selection

2007-09-30 Thread Florian Weimer
* Kurt Roeckx:

 - A simular case is that you have 2 segments, 1.0.0.0/24 and 1.0.1.0/24,
   and you add a 1.0.0.2 and 1.0.1.2.  Now you want clients to connect
   to the one from it's own segment, and fall back to the other if it
   fails.

   In this case rule 9 might be useful.  But I would rather see that this
   fall under rule 2 and/or 8, and that such address would be considered
   one with a site-local scope.  It could potentially also fall under
   rule 4.  It's also something that can perfectly be configured in the
   policy.

Scope is not defined for IPv4 addresses (neither in RFC 3484 or
elsewhere), so Rule 2 and Rule 8 do not apply in this case.


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



Re: glibc's getaddrinfo() sort order

2007-09-24 Thread Florian Weimer
* Anthony Towns:

 FreeBSD 6.2, Jan 2007: stable, but not rule 9

   10:00 gjb {'96.96.96.96': 1000}
   10:00 aj what os?
   10:00 gjb Python 2.4.3 (#2, Nov  8 2006, 23:56:15) 
   10:00 gjb FreeBSD 6.2-RELEASE-p5 i386 SMP-GENERIC
   10:34 gjb aj: it was 172.16.x.x, nat'd behind 203.y.y.y

On FreeBSD 6.2, I get:

{'144.144.144.144': 66, '64.64.64.64': 67, '240.240.240.240': 66, 
'32.32.32.32': 67, '208.208.208.208': 67, '96.96.96.96': 67, '192.192.192.192': 
67, '112.112.112.112': 66, '160.160.160.160': 67, '176.176.176.176': 67, 
'80.80.80.80': 66, '16.16.16.16': 67, '48.48.48.48': 66, '128.128.128.128': 67, 
'224.224.224.224': 67}

This is with a BIND 9 resolver in the default configuration (IOW, it
performs round-robin).

 Fedora Core 5, March 2005: stable

   10:02 Jerub {'128.128.128.128': 1000}
   10:03 aj jerub: os?
   10:03 Jerub aj: fedora core 5, behind a caching bind server.

Does that BIND perform round-robin address selection?


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



Re: glibc's getaddrinfo() sort order

2007-09-23 Thread Florian Weimer
* Clint Adams:

 On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
 glibc is the only implementation I know of that does this.

 I have heard, though not confirmed first-hand, that modern
 versions of FreeBSD, Windows, and Solaris do as well.

FreeBSD 6.2-RELEASE doesn't do it.  And neither does Fedora (with GNU
libc 2.6.90-15, IPv6 not enabled).  (Windows is an entirely different
matter because the resolver model is completely different.)

You can run the following test program repeatedly to check if every A
record gets its chance.

import socket
print ', '.join(map(lambda x: x[4][0], 
  socket.getaddrinfo('pool.ntp.org', 123, 0, socket.SOCK_DGRAM)))


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



Re: glibc's getaddrinfo() sort order

2007-09-22 Thread Florian Weimer
* Anthony Towns:

 I don't agree with making a decision to go against an IETF standard

RFC 3484 is not an IETF standard.


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



Re: Bug#413926: wordpress: Should not ship with Etch

2007-03-12 Thread Florian Weimer
* Anthony Towns:

 Viewed this way, wordpress definitely appears to have one of the /highest/
 rates of security holes for webapps of its class.

 14 bugs per year versus 12 for moodle and phpbb2 doesn't seem that big
 a difference to me.

 I'm not sure that bug counts like this are really useful though -- they
 don't measure the severity of the problems, and could be indicative of
 popular code that's being regularly fixed as much as low quality code
 that's being regularly broken.

Unfortuantely, our severity ratings aren't very good (this covers only
bugs from 2005 onwards):

moodle|low|5
moodle|medium|4
moodle|unimportant|5
moodle|unknown|9
phpbb2|high|1
phpbb2|low|4
phpbb2|medium|5
phpbb2|unimportant|16
phpbb2|unknown|15
wordpress|high|1
wordpress|low|5
wordpress|medium|7
wordpress|unimportant|11
wordpress|unknown|15

Apart from that, I'm not sure how much meaning we should attach to
these numbers, even if we had a higher number of vulnerabilities and
more rigorous analysis of each one.  (For instance, #363580 is
apparently not included in the counts above.)

From a software quality point of view, wordpress shares many of the
design flaws typically found in PHP applications.  For instance, it
does not use prepared statements, and consequently does not separate
SQL statements and their parameters in a way that can be audited in a
straightforward manner:

wp-includes/registration.php: return $wpdb-get_var(SELECT ID FROM 
$wpdb-users WHERE user_email = '$email');

The function that guards $email against malicious characters is
contained in the file wp-includes/formatting.php, without any hint
that it is security-relevant.

In another case, it's less clear if it's impossible to inject SQL via
the configuration option start_of_week.

wp-includes/general-template.php: $arcresults = $wpdb-get_results(SELECT 
DISTINCT WEEK(post_date, $start_of_week) AS `week`, YEAR(post_date) AS yr, 
DATE_FORMAT(post_date, '%Y-%m-%d') AS mmdd, count(ID) as posts FROM 
$wpdb-posts WHERE post_type = 'post' AND post_status = 'publish' GROUP BY 
WEEK(post_date, $start_of_week), YEAR(post_date) ORDER BY post_date DESC . 
$limit);

AFAICS, that option is not properly sanitized when it is being set.

Wordpress includes a private copy of ezSQL (LGPLed, according to an
extremly brief statement by upstream), without proper attribution in
the debian/copyright file.

But all that can be considered best current practice, so to speak, and
should not necessarily be a reason to exclude a package from a stable
release.  There might be non-technical concerns regarding the promises
of security support or the maintenance status in Debian, but I'm not
qualified to judge that.


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