Re: CVE Cross references

[Florian Weimer]

* Steve Mouer:

> Hello,
>
> We are using your CVE cross references list to understand impact of
> vulnerabilities across Debian Security advisories, however all of
> the information has disappeared from the following page:
>
> https://www.debian.org/security/crossreferences
>
> Can you please advise if this will be restored and is this the best
> place for us to automatically pull this information?

Thomas, any idea what might be causing this?

Running the generator script locally in the right directory does
produce some data.  Could this be the proper fix?

diff --git a/english/security/Makefile b/english/security/Makefile
index d1bda4969f1..271dcd02bc0 100644
--- a/english/security/Makefile
+++ b/english/security/Makefile
@@ -51,7 +51,7 @@ faq.$(LANGUAGE).html: faq.wml \
   $(ENGLISHSRCDIR)/security/faq.inc $(GETTEXTDEP)
 
 $(ENGLISHSRCDIR)/security/ref-table.inc: 
$(ENGLISHSRCDIR)/security/make-ref-table.pl $(sort $(wildcard 
$(ENGLISHSRCDIR)/security/*/*.data)) 
-   perl $(ENGLISHSRCDIR)/security/make-ref-table.pl -p -a 
>$(ENGLISHSRCDIR)/security/ref-table.inc
+   cd $(ENGLISHSRCDIR)/security && perl make-ref-table.pl -p -a 
>ref-table.inc
 
 crossreferences.$(LANGUAGE).html:: $(ENGLISHSRCDIR)/security/ref-table.inc \
$(ENGLISHDIR)/template/debian/securityreferences.wml 

Re: Keysigning in times of COVID-19

[Florian Weimer]

* Philip Hands:

> If I were a sociopath contemplating sabotage in the Free Software
> sphere, going to the effort of becoming a DD, even for the first time,
> would be nowhere near the top of my list.

Even if you got a peer-reviewed research paper out of it?  (If I
recall correctly, academics already set up a fake Debian mirror and
wrote a paper about it.)

Re: Testing Discourse for Debian - Moderation concepts

[Florian Weimer]

* Ansgar:

> I'm not concerned about marking messages read after some time and
> keeping the view time in ephermal storage for that.  But that's not
> what Discourse does: as described elsewhere it stores all read times
> persistently on the server; that would not be neccessary for marking
> posts as read even on a web application.
>
> I feel it dishonest to compare storing data persistently in a database
> and evaluating it for statistical purposes (or other analytics that
> people come up with to increase participation and measure community
> engagement for community building) with keeping data in ephermal
> storage for a short while.
>
> Evolution also keep track of the mouse cursor, but that is something
> different from recording clickstreams and evaluating them to increase
> user participation as some people do. Your reply seems to put both on
> the same level.

It's also not clear whether the presentation requires
message-read-state for every addition to a discussion thread.  From
the user perspective, it might be sufficient to record the last
scroll-down position.

What I find concerning is that Discourse (the web application) does
not clearly communicate how it shares the data it collects about me
with users.  For example, it seems to notify other users that I'm not
active on the site, next to my posts, without showing me that
information.  Using message-read information could be used for similar
notifications.  And with the gamification tendency, users might not
even be aware that such information is available to users at higher
privilege levels (with better scores).

Re: Some thoughts about Diversity and the CoC

[Florian Weimer]

* Dato Simó:

>> If it turns out that […] what I think […] is unacceptable
>> rather than the way I express it, I will not post any more.
>
> Well, that’s the crux of the problem, isn’t it?
>
> On one hand, there is a clear consensus in the community that
> misgendering someone is something we —Debian— do not tolerate.
> That we’ve chosen to respect the gender identity of our members,
> and prospective members.
>
> On the other hand, someone wil inevitably say: so in order to meet
> the letter of the CoC on this point, it should be enough not to
> misgender any one person in particular, right? Not quite so, in my
> opinion.
>
> The following sentence, and the whole paragraph that contained it,
> said on a Debian mailing list is, in my opinion, in full violation
> of the Code of Conduct, no matter how politely expressed:
>
>> I do not feel that I should acknowledge people’s requests to refer
>> to them by their preferred pronouns […]
>
> Why?
>
> We —Debian— haven’t chosen to respect gender identity as a mere
> courtesy to some members, but have —hopefully— integrated it fully
> into our ethos, the one which wants our members to feel not only
> welcome, but safe. And that must come with consequences, if we
> want to be coherent and not merely pay lip service to diversity.

Not necessarily.  It is possible to avoid pronouns altogether even
when talking about specific persons.  Just repeat their names as
needed.  Possibly rephrase what you write so that there aren't too
many such repetitions (which could impact readability).

Some people have said in other contexts (for other code of conducts)
that this would be in violation, but I don't think that's the Debian
view.

Some cultures have a lot of practice in this area because the choice
of pronoun strongly implies a register.  If you are unsure about the
social relationship and how a particular choice will be perceived, you
are forced to avoid them altogether.

Re: Ihr Artikel über Check_MK

[Florian Weimer]

* Jan Leptien:

> Sehr geehrte Damen und Herren,
>
> mein Name ist Jan und ich arbeite für tribe29, dem Team hinter Check_MK.
> Ich melde mich bei Ihnen, weil ich einen Artikel zu Check_MK gefunden
> habe, den Sie geschrieben haben: http://www.debian.org/consultants/

Please follow the procedure outline here for updating that page:

  

Re: Debian and Non-Free Services

[Florian Weimer]

* Ole Streicher:

> You may guess that people using github accept pull requests, but you
> even can't see whether they actually like them -- there are many reasons
> why people use github, and PRs may not necessarily the specific reason
> for the repository.

And you can't disable this Github feature, so its availability tells
others nothing about maintainer preferences.

I've grudgingly submitted pull requests over Github, only to be told
that no, we don't accept patches here. 8-(

But nevertheless, I think the canonical source location is useful
information, especially in a machine-readable form.

Re: Using Debian funds to support a gcc development task

[Florian Weimer]

* John Paul Adrian Glaubitz:

> But I think the list on the page archive criteria is a bit dishonest as
> well when it asks "Are machines available to buy for the general public?"
> while I don't think an IBM Z mainframe is available to buy for the general
> public.

At last for upstream, the difference is that (I assume, I have no
direct evidence) IBM uses revenue from their Z business to fund
upstream development, and they do more than the required minimum to
keep the port working.  In that sense, the existence of the Z port is
probably not a burden on upstream as a whole (more likely the
opposite—but I haven't run any numbers, and those would likely be hard
to come by).

A contribution of the cc0 switchover to GCC could help upstream if it
removes the last remaining cc0 port and thus enables some generic
infrastructure cleanup.  The latter would obviously benefit upstream
as a whole.  But it's still a one-time thing.  It does not move the
port towards a more symbiotic upstream relationship.

The downstream perspective might be quite different, but we are
talking about funding upstream work.

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Florian Weimer]

* Vincent Bernat:

> Because without uniformity, we make it harder for people to contribute.
> I have already mentioned Fedora that provides everything in git with CI
> enabled, ability to contribute with pull requests, but that's far the
> only proponent.

Fedora still uses VCS-in-VCS, so it's not real Git.  You cannot simply
send a pull request for anything that changes source code.  You still
have to create a patch file and add it to the RPM spec file.  Some
package maintainers have their true repositories elsewhere and
synthesize the patches from that, but there's no standard way of doing
that yet.  (packit is not yet integrated with Fedora infrastructure,
and it is quite new.  It's unclear if it will fare better than the
many previous attempts.)

Re: anti-tarball clause and GPL

[Florian Weimer]

* Adam Borowski:

> In the light of the currently discussed GR proposal, I wonder if the
> following license clause would be considered DFSG-free and GPL-compatible:
>
> ##
> I do not consider a flat tarball to be a preferred form for modification. 
> Thus, like any non-source form, it must be accompanied by a way to obtain
> the actual form for modification.  There are many such ways -- unless you
> distribute the software in highly unusual circumstances, a link to a
> network server suffices; see the text of the GPL for further details.
> ##
>
> I believe such a statement would be GPL-compatible; rationale:
> * by the 2011 Red Hat kernel sources outcry, it is obvious such a tarball
>   is long obsolete
> * a flat tarball deprives the recipient of features of modern VCSes
> * comments giving rationale for a change tend to be written as VCS commit
>   messages
> * future forms are not banned: it is conceivable that next week someone
>   invents a revolutionary new form that wins over git
>
> Thoughts?

The GPL version 2 already requires that you maintain something like a
ChangeLog:

|   2. You may modify your copy or copies of the Program or any portion
| of it, thus forming a work based on the Program, and copy and
| distribute such modifications or work under the terms of Section 1
| above, provided that you also meet all of these conditions:
| 
| a) You must cause the modified files to carry prominent notices
| stating that you changed the files and the date of any change.

On the other hand, not allowing source distribution as a “flat
tarball” sounds like an additional restriction, which would be
incompatible with the GPL.  (Just like parts of glibc used to require
distribution on tapes, only less inconvenient.)

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa

[Florian Weimer]

* Bastian Blank:

> On Wed, Jul 24, 2019 at 01:46:36AM +0200, Thomas Goirand wrote:
>> On 7/23/19 11:59 PM, Adam Borowski wrote:
>> > Big fat enormous NO!  gbp is a workaround for the biggest evil in our
>> > packaging: quilt.  Watching pro-git-only talks on the Debconf, I got the
>> > impression that if we dropped the VCS-in-VCS approach, there'd be no need
>> > for most of that complexity.
>> How do you track what you've applied in Debian, and the status of your
>> patch upstream? With DEP3 patch headers in d/patches, we track this easily.
>
> git cherry-pick to get new changes. git diff to get all changes, git log
> to list changes.  You just need to know the branch point.
 
I expect you'd need some more tool support to find backports that did
not properly converge after an upstream merge (that is, importing a
new .orig.tar.gz in the current model), so that you can be aware and
remove the lingering difference.  For partially diverging trees, “git
diff” might be a bit too much.  However, I do think that such tooling
will be far simpler and more deterministic than any two-way Git
importer (having written one of those for RPM spec files, complete
with LCS-based editing of Patch:/%patch directives).

But isn't a GR a bit premature?  I would have expected something to
build directly from salsa.debian.org first—like how Fedora builds from
Git repositories on src.fedoraproject.org.  I'd hope for something
without VCS-in-VCS, but even if you prefer that, but build-from-salsa
applies to any approach which mandates a centralized Git (in addition
to the already-centralized archive).

(I really hate VCS-in-VCS, although I know it primarily from a
non-Debian context these days.)

Re: metaphors and feminism

[Florian Weimer]

* Mike Hommey:

> That's the primary structural distinction as an effect, but OTOH, the NM
> process is a rather extensive vetting process.

Not all Debian Developers went through the NM process.  Account
creation was handled differently in the beginning.  (I wasn't around
and don't know the details.)

Re: Binary compatibility policy for security updates and point releases

[Florian Weimer]

* Jakob Leben:

> Well, there are use cases that are not so simple. For example: I might
> deploy Debian 9.1 on an embedded machine sold to a client on the other side
> of the world. I have a system for updating my own software which is also
> deployed on that machine, but not the rest of the Debian system. Now, if
> ABI might change between 9.2, then I have no guarantee that if I test my
> software update with 9.2, it will be work as expected on the client's
> machine with Debian 9.1.

Why do you care about ABI breakage in particular?  What about
regressions in functionality?

Practically speaking, you will have to run your own testing (probably
focusing on functionality).  ABI testing is rather hard, and while
there are quite a few tools for it, interpreting the results still
needs expert knowledge.  Sometimes we waive test failures, believing
they do not matter, when it fact they do.  Only testing will find out.

Re: Debian's Code of Conduct, and our technical excellence

[Florian Weimer]

* Matthew Vernon:

> There have a few posts in recent discussions by people suggesting (or, 
> at least, appearing to suggest) that there is a conflict between 
> technical excellence and our Code of Conduct (or aiming to increase the 
> diversity of our membership, or similar).
>
> I think there is no such conflict, and that the idea that there is is in 
> itself harmful.

I've also seen a suggestion that Debian is falling behind.  Which I
found even more puzzling because Code-of-Conduct-less Linux
distributions aren't easy to find these days, particularly among the
collaboratively developed ones.  So even if it were an impediment,
everyone else would be similarly afflicted.

> In particular, "X does excellent technical work, so we should turn a 
> blind eye when their violate our CoC otherwise the technical excellence 
> of the project will suffer" is both wrong and harmful. If we want to 
> achieve technical excellence, we will do so by having many talented 
> people working together. If we restrict our talent pool to "people who 
> are prepared to tolerate a toxic environment", then we are harming that 
> goal.

Sure.  And we can even take their patches, but do not invite them into
the fold (where they probably wouldn't be be comfortable anyway).  We
know that some upstream developers have political convictions and have
made choices in life most of us find completely unacceptable, but that
hasn't led us to backing out the code they've written.

Re: Do we need embargoes for GPL compliance issues?

[Florian Weimer]

* Russ Allbery:

> Florian Weimer  writes:
>> * Russ Allbery:
>>> Florian Weimer  writes:
>
>>>> Do you think Debian should welcome embargoes for GPL compliance
>>>> issues?  Security embargoes are a huge pain, but one would hope that
>>>> GPL violations by Linux distributions are much rarer events.
>
>>> I'm sorry, I think I'm missing some basic context required to make
>>> sense of this question (and therefore I suspect other people on this
>>> list are as well).
>
>>> What exactly would we be embargoing, and why?
>
>> See bug #907585 for an example.  It occurred to me only afterwards
>> that reporting it publicly (upstream) might be a bit inconvenient for
>> some people (although no one has complained to me directly).
>
> Hm.  I guess I'm not seeing any harm there.  The problem only happens if a
> copyright holder sees such a notification and then files a formal notice
> of copyright violation, right?

I suppose so.

Thanks for all the feedback.  I was just wondering if I was missing
something.  Reporting things publicly immediately is probably easier
for all folks involved, and is probably the only realistic way to get
issues addressed when it comes to linux-firmware upstream.  I can't
see reporters wanting to talk to lawyers over the phone during the
course of multiple months, which is what I suppose would happen in
case of private reports, even if the reporter does not have a
copyright interest.

Re: Do we need embargoes for GPL compliance issues?

[Florian Weimer]

* Russ Allbery:

> Florian Weimer  writes:
>
>> Do you think Debian should welcome embargoes for GPL compliance issues?
>> Security embargoes are a huge pain, but one would hope that GPL
>> violations by Linux distributions are much rarer events.
>
> I'm sorry, I think I'm missing some basic context required to make sense
> of this question (and therefore I suspect other people on this list are as
> well).
>
> What exactly would we be embargoing, and why?

See bug #907585 for an example.  It occurred to me only afterwards
that reporting it publicly (upstream) might be a bit inconvenient for
some people (although no one has complained to me directly).

Re: Do we need embargoes for GPL compliance issues?

[Florian Weimer]

* Jonathan Carter:

> Having said all of that, I don't know of any case where Debian has
> specifically named and shamed anyone regarding such a violation, but I
> also don't see a reason why Debian should explicitly try to keep those
> secret for no good reason.

The main advantage for Debian would be to retain licenses for GPLv3
software, despite the occasional accidental violation and the time
needed to clean up one.

However, the most likely source of accidental violations is the Linux
kernel (because it will increasingly end up in firmware blobs where
the upstream submitter claims they are non-free but redistributable).
Non-cooperative developers are unlikely to participate in the Common
Cure movement anyway, so the whole thing is perhaps moot.

Do we need embargoes for GPL compliance issues?

[Florian Weimer]

Do you think Debian should welcome embargoes for GPL compliance
issues?  Security embargoes are a huge pain, but one would hope that
GPL violations by Linux distributions are much rarer events.

I'm asking because even with the GPLv3 or the Common Cure
, the 30-day period seems awfully
short.  I don't think even organizations that care a lot about GPL
compliance (even formal compliance with exactly matching sources) will
be able to address an accidental violation in that time period.

Although the cure period only starts when notified by a copyright
holder, with a public notice, other, less cooperating copyright
holders might send a notification of their own and start another
clock.

Nothing can be done about GPLv2-only violations and the resulting
license termination, of course.

Re: Article 13 of the EU copyright review

[Florian Weimer]

* Chris Lamb:

> Would there any strong objections to the Project aligning itself
> against the new EU copyright review? For more background, here's a
> recent Linux Journal article about this reform attempt:
>
>   
> https://www.linuxjournal.com/content/how-eus-copyright-reform-threatens-open-source-and-how-fight-it

Which part?

I think the upload filters are fairly sensible, and Debian would
implement them if required in practice.  For us, infringing content is
low-quality content, and we train our users to avoid uploading it.
This is different for the likes of Youtube and Github.

I find it also problematic to suggest that copyright infringement is
somehow necessary for a thriving free software ecosystem.

I find Title IV, Chapter 3 (“Fair remuneration in contracts of authors
and performers”) far more problematic because as written, in seems to
effectively ban irrevocable free software licenses:

| Article 15
| Contract adjustment mechanism
| 
| Member States shall ensure that authors and performers are entitled to
| request additional, appropriate remuneration from the party with whom
| they entered into a contract for the exploitation of the rights when
| the remuneration originally agreed is disproportionately low compared
| to the subsequent relevant revenues and benefits derived from the
| exploitation of the works or performances.


(Apologies if this is not the current version.)

Germany already has similar provisions, but they exempt free
culture/free software licensing: these provisions do not apply to
works for which everyone has been granted basic exploitation rights.

So yes, we should do something about Title IV, Chapter 3, but I expect
that we'd be pretty much alone in that.

Re: Bitcoin donations

[Florian Weimer]

* Adam Borowski:

> I consider Bitcoin to still be far less repulsive than both the mainstream
> banking system and para-banks like Paypal.

Many countries have a long tradition of banking cooperatives, which
could provide a third option.

Re: Debian infrastructure in the EU / copyright challenges

[Florian Weimer]

* gregor herrmann:

> Question 2: What about the "uploads by their users"? Since Debian
> doesn't allow random people to upload random stuff to its servers
> which Debian then promotes, I think this also doesn't apply.

Correct, and Debian provides training to DDs to recognize potential
copyright infringement, and new packages also need to pass a separate
review step.

That leaves mailing lists and the wiki.  I don't see how
copyright-infringing content wouldn't be low-quality content as well,
so if that happens to a significant degree, we'd have to filter it
anyway to keep those resources useful.

Re: Debian infrastructure in the EU / copyright challenges

[Florian Weimer]

* Daniel Pocock:

> There has been some discussion about the potential impact of the latest
> copyright legislation[1] on sites/services that share source code or
> facilitate collaborative development services.

Do you have a link to the text of the proposal?  The EFF probably
misrepresents its contents.  It seems unlikely that a specific
approach to copyright review will be mandated.

I think we are already removing “meme”-type content from packages for
copyright reasons, so it is unclear to what extent Debian would be
affected.

Re: Publicly-readable list for only DDs and DMs to post to

[Florian Weimer]

* Ian Jackson:

> tl;dr:
>   pls can we create debian-members@l.d.o with posting acceptance rules
>   copied from debian-devel-announce[1] and subscriber list maintained in
>   sync with debian-private.

I think the only half-successful setups for such discussion lists
provide web-only read access.  If non-posters can subscribe, they are
tempted to take part in the discussion, only to be rejected, which is
bad because it rubs in the DD/non-DD distinction.

Even with web-only read access, Cc:s still have a strange effect.
Non-posters might try to reply to a Cc:ed copy, and their replies
propagate through the unrestricted parts of the Cc: list, but not to
the restricted list.  This isn't very welcoming, either.

Web archives without general posting privileges are also unfair to
those whose matters are discussed on the list, but cannot add to the
archives on their own.

In the end, the user experience is worse than a completely private
list.  At least it's easy to completely ignore the existence of such
lists if you are not a subscriber.

Re: DNS Qname minimisation

[Florian Weimer]

* Henrique de Moraes Holschuh:

> On the CDN side, Akamai were warned that their authoritative servers
> were broken and would interfere with Qname minimization in February
> 2015[1], and it is still not fixed.  It is the same bad behavior that
> happened to ECN

It is similar to ECN indeed.  In both cases, people changed the
specification, and complained loudly when their changes are
incompatible with the installation base.

In fact, the problem with NODATA responses is that it is rather
difficult for stub resolvers to tell a NODATA response from a working
recursive resolver from a “I don't provide recursive service” response
from a non-working recursive resolver.  NXDOMAIN would be unambiguous
in these situations.  It's likely one reason why most implementations
moved towards NXDOMAIN in the late 90s.

Re: Repository Link are NOT https://

[Florian Weimer]

* tom:

> I have discovered that non of the repository links is https:// . Is it
> not safer to use only https:// connections.

https:// is meaningless for package downloads because anyone can run a
mirror and see the requests directly, even if they are
transport-encrypted with HTTPS.

APT uses GnuPG to verify a signature on the repository, and chains
hashes from there, down to individual .deb files.

Re: Survey on Bug Tracking Tools

[Florian Weimer]

* Dominik George:

> However, I (for one) am not so comfortable with your proceedings.
>
>  1. Your e-mail doesn't even carry a real name (and originates at
> Google Mail, in combination making it look a lot like spam).
> Why not send it from a university address with a readable name,
> making it look like it was send by an academic?
>
>  2. The data has to be entered in Google Docs / Google Forms. Excuse
> me, but weren't you saying you are reaching out to Free Software
> projects?

Google services are quite popular among the FLOSS crowd at large.
You might not see many Gmail posters on Debian mailing lists, but
this is increasingly an anomaly.


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

Re: Plan of action for Secure Boot support

[Florian Weimer]

* Colin Watson:

> On Wed, Jan 08, 2014 at 08:31:11AM +0100, Florian Weimer wrote:
>> Furthermore, we need to store the keys for all EV certificates (both
>> the certificate used for submission, and the certificate embedded in
>> the shim) in devices that meet at least FIPS 140 Level 2.  Such
>> devices that are affordable, support secure, remote operation, and are
>> compatible with free software environments are difficult to find.
>> (But perhaps we can find a DD who agrees to keep the keys in his or
>> her home and manually signs our kernels, using Windows if necessary.)
>
> We (Canonical) have been trying to get this requirement made a bit more
> sane; we keep our SB root certificate split up among a number of
> shareholders using gfshare, which we believe should be functionally
> adequate for this.  Steve Langasek may know where this sits.

Have you had any success in this endeavor?


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

Re: Why discussions don't move from debian-private

[Florian Weimer]

* Brian Gupta:

> Could this be addressed by a moderated "public" list, that only allows
> DDs to post?

Unless we provide just a public web archive (which isn't really
desirable for a mailing list, with restricted posting or not), people
blocked from posting will respond with their mail clients, Cc:ing
subscribers.  Subscribers will respond to these messages, causing
confusion and threads with holes.  It's not a very good technical
solution.

(I don't think the occasional discussion on -private which could be
public from the start is a real problem right now.)


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

Re: Possibly moving Debian services to a CDN

[Florian Weimer]

* Tollef Fog Heen:

> There's not really anything to be fixed, since you shouldn't be using
> HTTPS for that host yet.

Can't they serve it off an IP address that doesn't answer on 443/TCP,
to avoid confusion?


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

Re: Plan of action for Secure Boot support

[Florian Weimer]

* Ben Hutchings:

>> The Terms & Conditions of existing EV code-signing CAs do not permit a
>> code-signing end-entity certificate to be used for signing another
>> certificate, so we'd directly have to embed the end-entity certificate
>> used to sign GRUB and the kernel into the shim—or we'd have to ship
>> the EV root CA, but that would extend complete trust to that CA.  If
>> we embed the end-entity certificate, we need to submit a new shim to
>> Microsoft for signing each time the certificate changes (say, because
>> the previous certificate expired after a year).
>
> Presumably actual code signatures never expire (or rather, expiry should
> not be checked) - as that would mean mandatory upgrades just to keep a
> machine bootable.

It's not a technical issue.  The CA/subscriber agreement doesn't
permit making new signatures after the certificate has expired.

>> With KVM, we can boot another operating system after executing
>> unauthenticated (userspace) code, so the new policy seems to force us
>> to disable KVM per item 5 (b) (or extended Secure Boot to qemu-kvm,
>> which is practically impossible at present because we do not have a
>> signed userspace).
>
> MS can go and stick their collective head in a blender if they expect us
> to do that.

The usualy argument against disabling KVM is that in order to get KVM
support, you need to activate it in the BIOS.  I haven't seen enough
machines to tell if this is actually true.

>> There is also a significant technical limitation: The current
>> shim/grub/kernel combination is totally untested as far as revocation
>> is concerned.  Fedora does not blacklist kernels with known
>> root-to-ring-0 escalation vulnerabilities.
>
> Well, that would be almost all of them, right?

Yes, it would apply to all but the latest kernel.

>> This means that you can
>> just downgrade the kernel to a known-vulnerable version and lose all
>> protections allegedly provided by Secure Boot (as far as the Linux
>> side is concerned).  On the other hand, no one really wants to fix
>> this because it would mean that users cannot downgrade kernels anymore
>> to deal with regressions.
>
> I expect MS doesn't blacklist their old kernel versions, for exactly the
> same reason.  Or do they?

It's not clear to me what Microsoft's objectives are.  Kernel signing
might not be required if they only want to save the cost of read-only
recovery media.  Their installation/recovery kernel does not appear to
be equivalent to the real thing, and vulnerabilities in it would not
matter as long as the signature checking works (for both kernel and
userspace code) and no code with useful vulnerabilities runs before
user interaction.

There's an expectation nowadays that Secure Boot can protect against
careful implants, which is clearly not true on Linux because you could
just target the initrd or any of the early boot scripts, without the
need for any exploits.  Even on Windows, Secure Boot is unlikely to be
able to help against unknown implants (or malware injected into the
boot process), but it's likely that it enables a reliable recovery
path once malware is detectable (and before the malware can, in turn,
detect the detection—it's just like Core War).

Part of the problem is that Microsoft is extremely tight-lipped about
their objectives and policies.  As a result, we pick up isolated
aspects and assume they reflect an overarching grand plan.  But so
far, things we once took for granted (like the $99 fee to get started)
turned out to be just temporary.

>> In short, I think it is very hard for us to comply with the new
>> Microsoft guidelines.  It is also politically problematic because once
>> we comply, Microsoft could try to claim that mandatory Secure Boot is
>> not locking out anyone (because it's not just Fedora anymore).
>
> Because there are no Linux distributions made by anyone but RH, SUSE,
> Canonical and Debian?

I might not be up to date on this, but I think only Fedora promoted
Secure Boot, and likely did more for the broad acceptance of the
concept as such than Microsoft.  It's also pretty clear that
Microsoft's recent policy changes are partly influenced by Fedora's
Secure Boot capabilities.

Other distributions either didn't try very hard (no signature checking
after ExitBootServices, which is a valid interpretation of the UEFI
Secure Boot specification, but not compatible with Microsoft Secure
Boot) or explicitly decided against joining the Microsoft Secure Boot
ecosystem.


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

Re: Plan of action for Secure Boot support

[Florian Weimer]

* Ben Hutchings:

> However, there is now a blog post from Microsoft that supports what
> Matthew Garrett has been saying for a while - they may revoke the
> signature on a boot loader if signature verification is not extended to
> the kernel, including any mechanism to chain-load another kernel:
>
> http://blogs.msdn.com/b/windows_hardware_certification/archive/2013/12/03/microsoft-uefi-ca-signing-policy-updates.aspx
> (specifically point 5(b))
>
> This implies that when Secure Boot is enabled, only signed kernels and
> modules can be loaded and other features that allow code injection such
> as kexec, hibernation and /dev/mem must be disabled.

We also need to use an EV certificate in the shim—not just for
submission to Microsoft, but also for the certificate that signs GRUB
and the kernel (item 6 (a)).

The Terms & Conditions of existing EV code-signing CAs do not permit a
code-signing end-entity certificate to be used for signing another
certificate, so we'd directly have to embed the end-entity certificate
used to sign GRUB and the kernel into the shim—or we'd have to ship
the EV root CA, but that would extend complete trust to that CA.  If
we embed the end-entity certificate, we need to submit a new shim to
Microsoft for signing each time the certificate changes (say, because
the previous certificate expired after a year).

Furthermore, we need to store the keys for all EV certificates (both
the certificate used for submission, and the certificate embedded in
the shim) in devices that meet at least FIPS 140 Level 2.  Such
devices that are affordable, support secure, remote operation, and are
compatible with free software environments are difficult to find.
(But perhaps we can find a DD who agrees to keep the keys in his or
her home and manually signs our kernels, using Windows if necessary.)

I'm not sure if we can sign sid kernels because of the requirement to
sign production quality code only.

With KVM, we can boot another operating system after executing
unauthenticated (userspace) code, so the new policy seems to force us
to disable KVM per item 5 (b) (or extended Secure Boot to qemu-kvm,
which is practically impossible at present because we do not have a
signed userspace).  Obviously, one can still start a virtualized
environment without hardware support, and I don't know what this means
for compliance.

I wonder why Microsoft no longer wants to sign GPLv3 code (such as
GRUB 2).  It could be due to plans to make Secure Boot mandatory
eventually.  Right now, it is possible to comply with the GPLv3
license requirements because users can switch off Secure Boot, either
at the BIOS level or through the MokManager loophole.  This does not
affect us because we rarely ship hardware with Debian pre-installed,
and if we do, we can make use of the general GPLv3 opt-out clause.
But it would affect some of our users.

There is also a significant technical limitation: The current
shim/grub/kernel combination is totally untested as far as revocation
is concerned.  Fedora does not blacklist kernels with known
root-to-ring-0 escalation vulnerabilities.  This means that you can
just downgrade the kernel to a known-vulnerable version and lose all
protections allegedly provided by Secure Boot (as far as the Linux
side is concerned).  On the other hand, no one really wants to fix
this because it would mean that users cannot downgrade kernels anymore
to deal with regressions.

In short, I think it is very hard for us to comply with the new
Microsoft guidelines.  It is also politically problematic because once
we comply, Microsoft could try to claim that mandatory Secure Boot is
not locking out anyone (because it's not just Fedora anymore).

We could still do our own thing under a root we control, but then we
have to decide if we want to cross-certify everyone else.

We should probably continue the discussion on debian-project because
it's not just about the kernel or technical issues.


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

Re: Updates in stable releases

[Florian Weimer]

* Kurt Roeckx:

>> If upstream has long-term stable versions with really limited changes
>> (your linux and postgresql-9.1 examples), we may use them instead of
>> rolling our own releases, based on the assumption that the released
>> version has seen some testing upstream and elsewhere, more than our
>> backport of a patch in isolation would receive prior to a release in a
>> Debian update.
>
> So I have the impression that if upstream has a stable branch and
> really only do bug fixes with a low chance of regressions that
> this will most likely be accepted.

Yes, that's the idea.  It's the contents that counts, not so much the
version number.


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

Re: Updates in stable releases

[Florian Weimer]

* Kurt Roeckx:

> I want to start by giving some examples of things that got updated
> in stable point releases that I know about:
> - linux was 3.2.41-2 in 7.0, 3.2.51-1 in 7.3, 3.2.53-2 in
>   proposed-updates
> - iceweasel was 10.0.12esr-1 in 7.0, is now 17.0.10esr-1~deb7u1
> - postgresql-9.1 was 9.1.9-1, now 9.1.11-0wheezy1
>
> Clearly new upstream releases are acceptable under some
> conditions.  But it's not clear to me what those conditions are.

There's not a consistent set.  For some packages, we end up with new
upstream versions because we have not much choice and would otherwise
have to remove the package.  iceweasel from your list falls into this
category, and there have been BIND and OpenJDK updates with similar
rationale.

If upstream has long-term stable versions with really limited changes
(your linux and postgresql-9.1 examples), we may use them instead of
rolling our own releases, based on the assumption that the released
version has seen some testing upstream and elsewhere, more than our
backport of a patch in isolation would receive prior to a release in a
Debian update.

> One thing I had in mind for an update to apache is to have the
> version in stable support ECDHE which the version in stable
> currently doesn't do.

I don't think we can switch to a new upstream version of Apache httpd.
But we do backport additional security features from time to time.
(The enhanced DNSSEC support that came with DSA-2054-1 is an example.)


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

Re: Should mailing list bans be published?

[Florian Weimer]

* Joey Hess:

> Simply obfuscating the name on the list of banned users (or not posting
> any names at all, only links to the posts that led to the ban) would
> eliminate most reputational damage. Ie, random searches for that
> person would not turn up a high pagerank debian.org page listing their
> youthful indiscretions.
>
> Using eg "J. Hess" would probably be fine in most cases.

I recommend to use a web page, and not announce bans on public mailing
lists because such announcements invite subsequent discussion, likely
decloaking the banned poster.

We could also add metatags/robots.txt exclusions to prevent indexing
of the page.


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

Re: Possibly moving Debian services to a CDN

[Florian Weimer]

* Simon Paillard:

> * My own experience is different, http.d.n redirects to ftp2.fr, which i got
> 10,2Mo/s, while cloudfront.d.n (Amazon) gives 5Mo/s.

This matches my experience.  One of the CDNs we use at work does not
seem to pre-replicate content world-wide (which is not too surprising,
I suspect this would be a poor trade-off for them), so when I download
an obscure package that none of our customers in close network
proximity to me has downloaded yet from the same CDN node, I get
relatively poor download rates.  Subsequent downloads of the same
package are faster, but performance is still not quite comparable to
local community-provided package mirrors.


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

Re: KickStarter for Debian packages - crowdfunding/donations for development

[Florian Weimer]

* Manu Sporny:

> As an aside, PaySwarm is currency agnostic. The commercial
> implementation of it (Meritora) deals with USD today, has plans for Euro
> (and a few other national currencies) within a year, and Bitcoin shortly
> after that.

For the Euro, we already have the SEPA system, which is very hard to
beat in terms of usability.  I strongly suggest not to re-invent that
particular wheel.

(Few U.S. consumers have fully-fledged giro accounts, that's why
services like Paypal can get traction over there.)


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

Re: Revising the Code of Conduct

[Florian Weimer]

* MJ Ray:

> I think "mailing list" is still usually two words, so I'd change that
> throughout.

And "list servers".

I think we should also mention that mailing lists are public (very
public at that, indexed by search engines and mirrored widely) if the
document is targeted a newcomers.

The discussion about Mail-Followup-To is best left out.  The advice is
difficult to follow for beginners anyway because many mail clients
have rather confusing choices when replying to list email.

(Personally, I'm *vary* annoyed by the discussions about Cc:s on list
email, coupled with claims that opting out of Cc:s via M-F-T doesn't
work, violates some RFC or is bad for the environment.)


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

Re: revenue sharing agreement with DuckDuckGo

[Florian Weimer]

* Stefano Zacchiroli:

> - The main risk I see in similar agreements is influencing our technical
>   choices by the revenues. By making clear --- to them and to us ---
>   that maintainers should be free to make technical decisions no matter
>   the agreements, I'm relatively confident this risk is moot.

How much money is expected?  I'm worried that strange things might
happen if it's a significant amount.

(I'm mainly concerned with the 25% option, the 50% option seems out of
the question for unrelated reasons.)


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

Re: revenue sharing agreement with DuckDuckGo

[Florian Weimer]

* Mike Hommey:

> With my iceweasel maintainer hat on, I won't start to consider ddg as a
> default until it at least matches the user experience the current
> default engine provides, including search suggestions and localized
> results (the latter requires some manual work ; the former lacks
> server-side support).

Curiously, localized search does not work for me in Iceweasel (on
squeeze), and this is actually a feature because I want to see
original content, and not a (potentially ad-infested) repost from
someone "local".


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

Re: Using corporate accounts when posting to Debian mailing lists

[Florian Weimer]

* MJ Ray:

> At least as I understand it (IANAL), English business emails should
> contain a signature with extended contact information (thanks to the
> Business Names Act, Companies Act, Distance Selling Regs and some
> other stuff that covers the gaps).

That stems from a European directive on business letters, so it's a
concern in Germany as well.  The downside is that once you add such
information to email, you might turn it into a business letter, which
creates other issues (people need to be properly authorized to make
such communication on the company's behalf, you need to arrange for
long-term archival &c &c).  That's why adding such a footer is
somewhat controversial.

> That went on a bit too long.  Why do you ask?

I was just curious about proper etiquette.  I'm still a bit worried
that corporatelessness is implicitly requested by the community.
Personally, I wouldn't want to see people using corporate mail on
official announcement lists, and I suspect many of us feel similar,
but it's not clear to me that this policy extends to other lists.


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

Re: Using corporate accounts when posting to Debian mailing lists

[Florian Weimer]

* Craig Small:

> On Wed, May 11, 2011 at 11:10:49PM +0200, Florian Weimer wrote:
>> I wonder if this is the result of corporate pressure, or if this is
>> somehow encouraged by the de-facto list policy.

> You'll never find me using a corporate address. The IP and surveilence
> rules are just plain crazy these days and I'd rather have all my Debian
> or other Free Software email go to a nice sensible mutt reader than get
> tangled into the corporate exchange servers. In fact, my corporate email
> address has no hits in google.

To clarify I bit, I was talking about using corporate addresses for
dealing with corporate matters (i.e., when we use Debian at work).
Those rules you refer to do not magically go away just because you use
your personal mail account or some anonymous web mail service.


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

Using corporate accounts when posting to Debian mailing lists

[Florian Weimer]

This is mostly an etiquette question, and I'm not sure if this is the
right mailing list to post to.

I've noticed that compared to, say, ten years ago, relatively few
mailing list posters use corporate accounts (or accounts readily
attributable to some larger organization).  This phenomenon is not
restricted to Debian mailing lists.  If the sender's mailbox looks
corporate (or the topic of the message involves stuff you usually do
not run at home), most of the time, no mail signature with extended
contact information (web, phone, fax) is used.

I wonder if this is the result of corporate pressure, or if this is
somehow encouraged by the de-facto list policy.


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

Re: No general political content on Planet

[Florian Weimer]

* Russ Allbery:

> Meeting one's fellow developer in person also (at least for me) helped a
> lot in turning random political content I strongly disagree with from
> something that pissed me off into something that just makes me roll my
> eyes and remember the good conversation we had.  :)

This certainly does not work for everyone.  I can't imagine that it
would work for me for certain policy positions---various kinds of hate
speech come to my mind.

Anyway, in any case, this could only restore respect for the poster
(whose speech I don't want to suppress, even my moral relativism goes
that far).  The fact that Debian supports such speech by its
dissemination would not be changed by that.


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

No general political content on Planet

[Florian Weimer]

Could we please make and enforce a rule that no general political
content is published on planet.debian.org and similar sites?

I understand that people have different political views, and I
generally appreciate that.  We have developers from countries who are
not on the most amicable terms, and countries which are politically
deeply devided.  I don't think we want to deal with the resulting
toxic debates.


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

Re: Debian accepting Social Micropayment?

[Florian Weimer]

* Russ Allbery:

> So far, these systems look like a great way for the micropayment broker to
> make money and rather iffy for everyone else involved.

For them, it's not about payment, but about clickstreams and related
data.


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

Re: Invite to join the Release Team

[Florian Weimer]

* Clint Adams:

> Okay, so when there is a mysterious release team meeting in Cambridge,
> and there is no discussion or planning of it on debian-release, or
> #debian-release, or anywhere else public that I can see,

http://lists.debian.org/debian-devel-announce/2009/03/msg00011.html
http://lists.debian.org/debian-project/2009/05/msg00080.html

So it wasn't that secret after all.  (Note that all this happened last
year, including Luk's tweet.)


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

IPv6 troubleshooting help needed

[Florian Weimer]

Now that security.debian.org has got  records, reports regarding
connectivity issues pop up in odd places.  The level of complaints is
still rather low (quite unexpected to me), and it's not affecting user
experience in a significant way (I think), but we should still try to
improve things where we can.

In short, we're looking for Debian Developers who help us to debug
IPv6 connectivity issues.  Here's the basic skill set (which may seem
a bit daunting, but if everything were easy, we wouldn't have anything
to troubleshoot, right?):

  - basic knowledge of BGP and real-world Internet WAN routing
and traffic exchange policies

  - ability to interpret looking glass output (show ip bgp, show
route) and traceroutes

  - some IPv6 experience preferred

  - basic understanding of DNS (A/ records,
proxy/forwarding/recursive/authoritative server distinction)

  - Internet2 routing knowledge is a plus (but certainly not a must)

  - non-English language skills would help as well

  - DD status required

Tasks include:

  - subscribing to the various mailing lists (debian-user, NANOG and
other *NOGs, outages, dns-operations, language-specific lists) and
monitor them for occurrences of security.debian.org

  - following up on reports, requesting more information if necessary

  - obtaining the reverse view from Debian's own hosts

  - try to guess where the problem is located (the hard part!)

  - contacting network operators in case of persistent issues

  - interacting with DSA if action on Debian's part is required

  - ask native speakers within Debian for help in case there's are
language barrier towards the reporter

The most frequent issues I've seen are related to partial transit from
Internet2, and broken DNS proxies taking  records and serving
their first four bytes as IPv4 addresses.  I don't think we've fully
debugged either set of issues, unfortunately.  The upside is that
large parts of the IPv6 community are friendly, accessible and eager
to help out when there are problems.

If you're interested, drop me a message.

Access to proper troubleshooting tools will require LDAP privileges
which are subject to DSA and security@ approval (hence the DD status
requirement).


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

Re: Switching the default startup method

[Florian Weimer]

* Tollef Fog Heen:

> I don't see anything in section 3 that makes it a bug for file-rc to
> update its own configuration file, as long as the admin's changes are kept?

Why can't file-rc use the correct order and warn if the configuration
file order is wrong?


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

Re: Debian on E-Bay (way: selling distributions)

[Florian Weimer]

* Alexander Reichle-Schmehl:

> On a case by case basis there have been successfully attempts to
> convince E-Bay that there is nothing wrong a specific auction,
> however E-Bay seems not to learn from such single incidents.  All I
> can find is a web interface which might be read by someone.  So,
> does anyone know a good way to get in contact with them?  Maybe a
> real human, whom we can talk to, and should know whose responsible
> for that?

Ebay simply disallows selling rewritable media with content
preinstalled (and consumer-writable media, too, it seems).  It's not a
simple oversight, it's a matter of policy.


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

Re: Genericly-named debian.net domains for private use

[Florian Weimer]

* Peter Palfrader:

> On Sat, 28 Mar 2009, Paul Wise wrote:
>
>> http://wiki.debian.org/DebianNetDomains
>> 
>> Nico Golde used to autogenerate a list of debian.net domains, but it
>> was replaced with the wiki page for "privacy reasons".
>
> The list of .net entries is not publicly available - the ldap only gives
> it out to debian.org hosts, and the zone should not be AXFR-able either.

This has to change because we will eventually sign debian.net, and if
we're aren't too slow about it, NSEC3 won't be feasible.


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

Re: Debian Membership

[Florian Weimer]

* Micah Anderson:

> There are some companies that have had their 'bottom-line' demonstrably
> impacted in significant ways by open source and have undertaken various
> dubious mechanisms to destabilize and discredit open-source. Microsoft
> actually acknowledged to the SEC[0] in its required filing[1] that it
> may be forced to lower its prices as a result of the growth in open
> source, the popularization of the open-source movement continues to pose
> a significant challenge to its business model...

Oddly enough, Microsoft funds quite a bit of free software
development, and we're distributing some of the results.  And
Microsoft will not do this simply because there is very little
benefit, and the risk of great losses--and they have to fear that
during the backslash, attacks from insiders on them might surface.  If
they want to destroy our community, they simply have to announce that
they'll provide Debian support in some way. 8-/

In any case, integrity of developer machines and the project
infrastructure is probably more of a concern than the NM process.
Citing security reasons as a justification to keep things as they are
in the NM process always sounds a bit racist to me.  This doesn't mean
we should open the floodgates, of course, but I strongly think that
voting rights should come *after* unmediated archive upload rights.


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

Re: Assisting with NEW queue backlog

[Florian Weimer]

* Wouter Verhelst:

> This will never happen, for legal reasons (unless you want us to set up
> a new non-US repository). Part of the requirements in doing the
> crypto-to-main transition was that uploaded packages would not be made
> available for download until some steps were taken first.

Except that a non-US repository won't help because the United States
nowadays have the most liberal rules for crypto export.


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

Re: Should this be sent to your bug center?

[Florian Weimer]

* Evan Larson:

> I am not using your OS but I am encountering a strange bug on my
> computer that says I am. When I try to navigate to en.wikipedia.org
> this is the page I encounter.

Hi Evan,

just to be sure, you entered "en.wikipedia.org" in the URL bar, and
that resulted in the message?

I think this is probably some sort of misconfiguration at
Wikipedia/Wikimedia.  Does the problem persist?

Florian


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

Re: Draft for lenny release announcement

[Florian Weimer]

* Gunnar Wolf:

> Now, Etch already included the out-of-the-box encryption support - I
> wrote an article on February 2007 specifically talking about this
> feature. I agree with announcing the graphical interface here, as it
> was hidden by default, but AFAIK the crypto part was already there (of
> course, exciting new developments in it might exist and warrant this)

It wasn't in the installer in March 2006, but beyond that, my memory
is foggy.  If you decide to mention this, please call it "full disk
encryption" (the boot partition doesn't count as far as the industry
is concerned).


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

Re: Yet another list statistics for debian-devel

[Florian Weimer]

* Steve Langasek:

> I thought complaining about sending these to each list would be "cure worse
> than the disease".  But if you're keeping score and taking the raw number of
> approvals vs. disapprovals as an endorsement, then count me among the
> disapprovers.

Me too.

Also note that publishing such aggregated data was once frowned upon
for privacy reasons, too.


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

Re: A Software Populist Who Doesn't Do Windows

[Florian Weimer]

* Ean Schuessler:

> http://www.nytimes.com/2009/01/11/business/11ubuntu.html 

> I do like how the article mentions Debian's 1000+ volunteers in
> place of a count of Ubuntu's. I also like Mark's lead quote:
>
> “It feels pretty clear to me that the open process produces better stuff,” 

In that spirit, here's a freely accessible reprint of the article:




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

Re: Spamming the World through Open Debian Mailinglists (Re: lists.debian.org has received bounces from you)

[Florian Weimer]

* Don Armstrong:

>> > We are aware that Debian-Mailinglists aren't 100% spam-free, but if
>> > you can't accept that, don't subscribe to our lists.
>> 
>> The spam-check is not even needed if you would simply close it, as I
>> wrote. 
>
> We aren't going to close the lists that are currently open in the
> forseeable future.

Thanks!  I hope you aren't forced to change this default configuration
anytime soon.  Being able to post to our mailing lists without jumping
through hoops, no matter who you are, is something I value, but I
understand that there is lots of work involved making this possible,
given the amount of spam that hits the lists.


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

Re: Voting on messages: a way to resolve the mailing list problems

[Florian Weimer]

* MJ Ray:

> Jurij Smakov  wrote: [...]
>> So, what can we do about? During a little brainstorming session on IRC 
>> last night a following idea has emerged: let's have a way to express 
>> our opinion about the mailing list posts. [...]
>
> So, people who remain on the debian mailing lists have a poor
> understanding of what should appear a good mailing list, but having
> those same people express their opinion about what is good on a
> mailing list will improve matters?  In short, we are going to use
> the "buggy" list memberships's views to repair the lists?

The proposal just assumes that there is a sufficiently large number of
readers who feed the moderation database.  This looks like a
reasonable assumption to me.

What I like about this proposal is that it will separate those who are
merely obnoxious in terms of behavior in mailing list discussions, and
those who intent to disrupt our community, for whatever reason, using
whatever means it takes.

I don't particularly like the policy implications, but if most data is
published (maybe after slight anonymiziation) and the scoring is done
locally, it should be fairly transparent and hard to abuse with good
intentions.  (I worry mor about misuse by well-meaning project
members, the lunatic fringe won't care anyway.)


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

Re: More frequent dinstall runs and mirror pushes

[Florian Weimer]

* Giacomo A. Catenazzi:

> I propose to do this after lenny release, when we will have
> more packages in the queue, and possibly a new way to handle
> the "Packages.diff/".
> I don't think that such diffs are designed for a lot of updates.

This is mainly a problem with the implementation of patching APT.
I've worked on a fix and shown that it's possible to bring the time
down from O(mn) (m hunks, n lines in the Packages file) to O(m² + n)
or even O(m log m + n), but the code is currently not useable for APT.


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

Re: Linux System Engineer (100%) in Zurich

[Florian Weimer]

* W. Martin Borgert:

> Quoting Andre Timmermann <[EMAIL PROTECTED]>:
>> We are searching for a system engineer in in Zurich,
>> Switzerland.
> ...
>> Requirements:
> ...
>>* Younger than 35 years
>
> I would very much appreciate, if Debian would not publish job
> offers that discriminate on the grounds of race, ethnic origin,
> disability, age, gender, sexual orientation or religion. Not
> only it is illegal in some countries, I find it highly
> inappropriate for our project.

I think it's a bit offensive, too.  A more agreeable way to put it is
"Entry level to 2 years experience" (from another job ad).


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

Re: Member distributions and popularity

[Florian Weimer]

* Noah Meyerhans:

> When Ean suggested borrowing ideas from Eclipse, I don't think he meant
> charge people to be Debian derivatives (or did you interpret it some
> other way?)

I don't know.  Paid membership by companies seems to be an integral
part of what Eclipse is doing in this area.


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

Re: Member distributions and popularity

[Florian Weimer]

* Ean Schuessler:

> This is how the Eclipse project works with their derivatives. Maybe
> we can borrow some ideas from them?
>
> http://www.eclipse.org/membership/special_programs/member-downloads-program.php

I think you missed this part:

| * Be an Eclipse member company

This costs at least USD 5,000 per year.  I don't think this is
suitable for Debian.


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

Re: call for seconds: on firmware

[Florian Weimer]

* Stephen Gran:

> It's not possible to express the full set of relations in a single
> winner vote, as far as I can tell.  It might be someone's vote to say
> 'none of this non-free crap in the archive ever' and simultaneously
> say 'but the release team does have the authority to downgrade these bug
> reports if they need to'.  Unless I've missed something and we're
> planning on having a multi winner vote, 

We can always put the elements of the power set of all proposals on
the ballot.

I suppose the ballot should be structured in a way that guarantees
halfway meaningful outcomes, while not actively discriminating against
certain proposals.  To be honest, I'm glad I need not decide such
things.


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

Re: Developer Status

[Florian Weimer]

* Joerg Jaspert:

> Following our Constitution §8.1.2, DAM declares that Debian Members are
> to be treated as "Developers who do not maintain packages" wherever the
> term "Developer" is used in one of our documents.

This strongly smells like abuse of procedure.  I know it's difficult to
implement this properly in Debian's framework, but can we please at
least try to do it that way?  The proposed approach might have some
unwanted consequences (like the Technical Committee deciding on full DD
status).

I'm also surprised that voting rights come before global uploading
rights.  Shouldn't that be the other way round?


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

Re: Debian and non-free

[Florian Weimer]

* David Paleino:

> Does RMS know all this? I don't think he'd support such kind of
> behaviour :)

Stallman tends to ignore moral rights/droit d'auteur concepts.

The GPL requires does not require preservation of the original copyright
notices.  It requires "appropriate" copyright notices, but the GPL
grants me a conditional exploitation right, so I've got a copyright
interest in the work, and could put my name on it.


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

Re: transfering files between *.debian.org hosts

[Florian Weimer]

* Peter Palfrader:

> What other options did we forget?

Modern NFS over IPsec to a central file server.  However, less than
stellar bandwidth at the Debian servers requires really, really modern
NFS with persistent caching.


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

Re: Open Invention Network

[Florian Weimer]

* Paul Johnson:

>> I guess they aren't aware that Debian doesn't hold any assests,
>> intellectual property or otherwise.  Perhaps you could try to clarify
>> that.  I'm pretty sure that afterwards, they will withdraw their offer
>> to join.
>
> Shouldn't they approach SPI instead?

SPI doesn't hold that many assets, either. 8-)


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

Re: Open Invention Network

[Florian Weimer]

* Steve McIntyre:

> I've been approached by the Open Invention Network[1]. They're asking
> if Debian would like to join as an organisation to "protect our work
> and support open access to intellectual property". I'm not sure either
> way myself, so I thought I'd ask for comments here. Any thoughts?

I guess they aren't aware that Debian doesn't hold any assests,
intellectual property or otherwise.  Perhaps you could try to clarify
that.  I'm pretty sure that afterwards, they will withdraw their offer
to join.


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

Re: get off your ass

[Florian Weimer]

* Craig Witherspoon:

> If you do not start doing something realistic about the NVIDIA drivers
> you are going to destroy your installed user base.

Our users buy their graphics cards from AMD, or use Intel on-board
graphics.  If Nvidea doesn't care about our market segment, there's
little we can do about it.


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

Re: dopewars do we need such a game in debian distribution?

[Florian Weimer]

* Julien Cristau:

> log/2005-05:20050528100016|lisa|rejected|hot-babe_0.2.0-1_powerpc.changes
>
> I can't find the reason, so you'd have to ask Jörg about that.

IIRC, the images are non-free, and might even be used without consent
from the copyright holder.

Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections

[Florian Weimer]

* Tollef Fog Heen:

> Maybe not, but plushy toys is something I feel this project is
> seriously lacking in.  I don't know how well a plushy swirl would
> work.

It would probably look a bit like a turd, especially if the color is
somewhat off.  So not such a good idea, I guess.

Pillows might work, though.


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

Re: State Museum of Pennsylvania - Debian copyright infringement?

[Florian Weimer]

* MJ Ray:

> If they made their logo independently and aren't using it for
> software, is there a problem?

Yes, if the swirl was a trademark, it would still be trademark
infringement.


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

Re: Need of non-germany-tree in Debian?

[Florian Weimer]

* Moritz Muehlenhoff:

> Plus, last time I checked setting a game on the index was strictly bound
> to specific versions of the game.

This was fixed a couple of years ago.


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

Re: Need of non-germany-tree in Debian?

[Florian Weimer]

* Holger Levsen:

> Hi,
>
> On Sunday 15 July 2007 01:36, Florian Weimer wrote:
>> Huh?  Distributing computer games without the necessary permission
>> under applicable youth protection laws is already forbidden.
> [..]
>> planetpenguin-racer is affected as well.  It doesn't matter whether
>> the game is violent or not.  There's only an exception for mostly
>> educational games.
>
> Wasn't there another exception if the game(s) is(/are) part of some
> bigger software bundle, i.e. a linux distribution?

I don't think so.  There's no such exception in §12 or §14 JuSchG
(<http://bundesrecht.juris.de/juschg/__12.html>,
<http://bundesrecht.juris.de/juschg/__14.html>).

Re: Need of non-germany-tree in Debian?

[Florian Weimer]

* Sven Hoexter:

> Florian Weimer wrote:
>
>> * Malte Hahlbeck:
>> 
>>> Today the upper House of the German Parliament (Bundesrat)
>>> decided to declare Security Software like nmap, nessus etc.
>> 
>> nmap (and probably Nessus as well, which is non-free these days
>> anyway) are unlikely to be covered by the new law.  I'm less sure
>> about packages such as john.

> Well the wording of the law is so vague that it needs to be seen
> against whom and what kind of software it will be used. While it
> should have created legal certainty it looks like it's going to be a
> huge mess which has to be cleaned up by judges.

Law tends to be technology-neutral, which has obvious benefits (and
some downsides).  What's causing people headaches is not a
technological weakness, but a legal one ("abstraktes
Gefährdungsdelikt" has tons of unwanted implications).

>> Technically, this is nothing new.  Keep in mind that we haven't got
>> permission to distribute most games in Germany, either.

> This issue might come up again if some plans for a new revision of
> those laws in question would be approved.

Huh?  Distributing computer games without the necessary permission
under applicable youth protection laws is already forbidden.

> And this time it could get interesting to see if someone has the
> will to argue about Q3A based games.

planetpenguin-racer is affected as well.  It doesn't matter whether
the game is violent or not.  There's only an exception for mostly
educational games.

> A security researcher or network admin might even argue that the law
> is against our constitution because it limits his free choice for a
> profession in an over exaggerated way.

Well, a pimp could claim that as well.  Keep in mind that most
security researchers aren't.

Re: Need of non-germany-tree in Debian?

[Florian Weimer]

* Malte Hahlbeck:

> Today the upper House of the German Parliament (Bundesrat)
> decided to declare Security Software like nmap, nessus etc.

nmap (and probably Nessus as well, which is non-free these days
anyway) are unlikely to be covered by the new law.  I'm less sure
about packages such as john.

Technically, this is nothing new.  Keep in mind that we haven't got
permission to distribute most games in Germany, either.


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

Re: Micros*ft deal

[Florian Weimer]

* Robert Millan:

> Since every GNU/Linux distributor seems to be positioning with regards to
> possible patent deals with Microsoft, I thought we could do the same.

The patent deals between Microsoft and Linux vendors that have been
announced so far deal with issues that do not seem particularly
relevant for the Debian project (except for the promise not to sue
some people).

If Microsoft promises not to sue us, our mirror operators, and or end
users, for no compensation except a joint press release (we haven't
got much more we can offer anyway), it would be very stupid to reject
such a deal.  Surely, it would legitimize Microsoft as a patent-owning
software company, but I can't really think this is particularly
relevant at this stage.  The business world doesn't see them as
mobsters, and neither do most people in software (not anymore).


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

Re: gpg changesets

[Florian Weimer]

* Anthony Towns:

> Two ways: either parse the output of gpg as it's running:
>
>gpg: requesting key CA57AD7C from ldap server keyserver.pgp.com
>gpg: key CA57AD7C: "PGP Global Directory Verification Key" not changed
>gpg: Total number processed: 1
>gpg:  unchanged: 1

Uh-oh.  You really, really should use "--with-colons --fixed-list-mode".
In addition, you should keep an explicit list of primary user IDs; I
don't think you should trust GnuPG's choice for this application
(which will be poor unless you've assigned a lot of trust values,
for which there isn't a real basis).


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

Re: Bits from the DPL: DSA and buildds and DAM, oh my!

[Florian Weimer]

* Frank Küster:

>> We aren't prepared to deal with that in some important cases.  For
>> instance, if large numbers of identically-versioned binary packages
>> are published, there will quite a few issues in the short term .
>
> Hm, what problems are you talking about?

Right now, if there's a bug report in the BTS that, for example, cook
2.26-1 has been miscompiled on amd64 and has got an important bug as a
result, we can be pretty sure that the submitter talks about the
version in our archive.  If there was a separate buildd network that
did not upload to the official archive and was somewhat popular among
our users[1], it's no longer obvious which version is broken.  (And
for interoperability with various bug tracking efforts, you'd really
want to keep the official version numbers.)

[1] It could be more up-to-date, use more conservative GCC defaults
(-fwrapv -fno-strict-aliasing -fstack-protector), or provide an audit
trail that gives people a warm fuzzy feeling.

>> (and fear of such confusion already led to drastic measures on
>> behalf of the project)
>
> What measures?  Can you provide any links?

Re: Bits from the DPL: DSA and buildds and DAM, oh my!

[Florian Weimer]

* Anthony Towns:

> If they don't do it, and it's important, someone else will.

We aren't prepared to deal with that in some important cases.  For
instance, if large numbers of identically-versioned binary packages
are published, there will quite a few issues in the short term (and
fear of such confusion already led to drastic measures on behalf of
the project).


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

Re: Bits from the DPL: DSA and buildds and DAM, oh my!

[Florian Weimer]

* Anthony Towns:

> I'm trying to be descriptive here rather than prescriptive or
> proscriptive

Does this mean that this message is not meant to create any new
delegations?  Below you say otherwise, so I'm confused.

>   * Debian System Administration (DSA)

>  - delegated authority to determine unofficial Debian services via 
> delegation
>of debian.net subdomains

Hasn't debian.net DNS management delegated to others?

> In my opinion the only roles that have any "DPL delegation" part are the
> ones I've described as "delegated authority" above -- ie, DAM's ability
> to determine who's a Debian developer, and DSA's management of the
> debian.org and debian.net domains.

Among other things, ftp-master decides what's acceptable for the
archive (see the Java 5 addition if this is not clear), and IMHO, this
activity needs delegation, too.  But according to my reading of the
Constitution (Article 2.1(2)), you cannot delegate to a team you are a
member of, anyway.

I'm positively surprised that DSA and keyring-maint themselves want to
use RT to improve their communication.


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

Re: gpg changesets

[Florian Weimer]

* Joey Hess:

> * Each change to the gpg keyring is stored in a separate changeset file.
>   Changesets can reflect any set of changes to the keyring. Changesets
>   can also include arbitrary metadata.
> * Changesets are never removed or modified, only new ones added.
> * There's an ordering of the changesets. This ordering is stored in an
>   index file.

The index file isn't necessary if you use hash-based chaining, like
several SCMs relying on hash functions do (Monotone, GIT, probably
Mercurial, too).


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

Re: Debian logos and trademarks

[Florian Weimer]

* Bastian Venthur:

> See what I mean? Maybe I'm missing something obvious here, but isn't
> that a contradiction?

FWIW, I agree there is an apparent contradiction.  In German legalese,
it's called "venire contra factum proprium" and can it make it
significantly harder (or even impossible) to successfully sue someone
who disagrees with you how the conflict should be resolved.

We shouldn't pamper over our internal conflict on this matter by
adopting a highly ambiguous position.  Ambiguity is a common mode of
conflict resolution, but it comes back to haunt you sooner or later.


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

Re: Position Statement to the Dunc-Tanc "experiment"

[Florian Weimer]

* Marc Haber:

> Please note that this is not a salary which can be relied on coming in
> month after months. Freelance people which high qualifications have to
> calculate differently. I am actually surprised that people on this
> list are not aware of these differences.

You make this sound as if the RMs had come up with the $6,000 figure,
which isn't true AFAIK.


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

Re: Improving the DAM-queue?

[Florian Weimer]

* Joerg Jaspert:

> On 10804 March 1977, Reinhard Tartler wrote:
>
>>>From my observations, is seems that the only persons who can judge about
>> these questions are the current DAMs (James and Joerg), and perhaps the
>> DPL, since only they can approve new members of FD and DAM. (Given that
>> I understand the current practice correctly).
>
> The constitution forbids the DPL to do the account management stuff.

Read again what Reinhard wrote.  The DPL surely can delegate acocunt
creations to developers of his choice, see §8.1(2).

By the way, do you consider yourself a delegate as far your DAM task
is concerned?

Re: Debian firefox

[Florian Weimer]

* Bastian Venthur:

> Maybe, but that was not my point. I somehow have the impression that
> some people think firefox is non-free (or sort of) just because Debian
> has to rebrand it.

I think you mean "unbrand".  Including our own logo with similar
restrictions would be somewhat embarrassing.


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

Re: Filibustering general resolutions

[Florian Weimer]

* Andreas Barth:

> perhaps we should, independend of current GRs, consider how to change
> the GR procedure so that it doesn't happen to be as painful as it is
> now.

Perhaps pain is highly subjective in this case.  I guess it's less
bizarre if you've been exposed to Robert's Rules of Order.  (But I
still think that the Rules themselves are horrible.)


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

Re: Hardware

[Florian Weimer]

* Pat Tadgerson:

> I am not a real hardware person, but I would like a server with 2
> hard drives with about 160 gigs of storage, with a raid 0
> configuration.

RAID 0 is usually a very bad idea because you lose all your data if
just one disk fails.

By the way, you should use a more suitable mailing list for such
questions.  Perhaps debian-user, but I'm not sure.


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

Re: RE : Re: RE : Re: Linux Magazin Germany, affecting Debian's image?!

[Florian Weimer]

* Andreas Barth:

> Does that sound like a wrong thing only to me?

No, this whole thread is rather bizarre.  It would be very sad if
someone reading it got the impression that this is the way the Debian
project interacts with other organizations, especially commercial
entities.


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

Re: RE : Re: RE : Re: Linux Magazin Germany, affecting Debian's image?!

[Florian Weimer]

* Radu-Cristian FOTESCU:

>> Please provide legal references for the "responsibilities" that you
>> persist in claiming someone has. To whom do you think those
>> "responsibilities" are owed?
>
> If you don't care about your brand, you'll lose the respect of your
> partners.

Well, you don't gain their respect if you start suing your supporters,
either (or exercising any form of public pressure, for that matter).

Trademarks and free software do not mix well.  Usually, the best
strategy is to establish a trademark and let it dilute.  As a result,
no third party can successfully monopolize the name, and few problems
occur if a fork should become necessary.


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

Re: Donations

[Florian Weimer]

* Manoj Srivastava:

> 
>  4. The Developers by way of General Resolution or election
>4.1. Powers
> Together, the Developers may:
> +6. Together with the Project Leader  make decisions about
> +   property held in trust for purposes related to Debian. (See
> +   §9.).  Such decisions are made by announcement on a 
> +   electronic mailing list designated by theProject Leader's 
> +   Delegate(s), which is accessible to all developers. 
> -
>
> So, we can disburse funds privately, if we wish, but there is
>  still a modicum of oversight, since  any DD  would have access to
>  it.

Shouldn't this be parallel to the second instance below, that is
"designated by the Project Leader or their Delegate(s)", instead of
requiring delegation?

Re: Donations

[Florian Weimer]

* Manoj Srivastava:

> On 11 Jun 2006, Martin Wuertele stated:
>
>  ]Since Debian has no authority to hold money or property, any
>  ]donations for the Debian Project must be made to any
>  ]one of a set of organizations designated by the Project leader
>  }  or a delegate to be authorized to handle such things in name
>  ]  of the Debian project. 
>  \footnote{Historically, Any property in hardware, trademarks, or in
>  copyright was handled by SPI, our original legal umbrella organization
>  in the U.S.}
>
>
>> Why limit the change to monetary donations?
>
> No reason.  I also changed allowed -> authorized,  and added
>  allowed for the possibility of delegation.  How does this sound?

I'd like to see a requirement that such authorization must be public.
Something like "Such authorization, or its withdrawal, must be
published on an appropriate Debian mailing list."


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

Re: Donations

[Florian Weimer]

* MJ Ray:

> any donations to debian must be given to SPI; or

Why do you think this is so?


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

Re: [SUMMARY] About terminology for stable/testing/unstable and related issues

[Florian Weimer]

* Adam D. Barratt:

> On Tuesday, May 09, 2006 6:26 AM, Florian Weimer <[EMAIL PROTECTED]> wrote:
>
>> * Christian Perrier:
>>
>>> Most concerns have been raised about my proposed use of "branch" for
>>> talking about stable/testing/unstable. "Suite" seems better...suited,
>>> indeed.
>>
>> Suite has already been used informally.  For completeness, you should
>> also mention "section" (main, contrib, non-free)
>
> Those are components in Debian's nomenclature. Sections are the next level
> down.

Policy 2.2 calls them "sections" or "categories" (depending on whether
you go with the headline or the main text).  One place the term
"component" is used is APT, but I don't think this is an authoritative
reference (cf. the use of "distribution").


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

Re: [SUMMARY] About terminology for stable/testing/unstable and related issues

[Florian Weimer]

* Christian Perrier:

> Most concerns have been raised about my proposed use of "branch" for
> talking about stable/testing/unstable. "Suite" seems better...suited,
> indeed.

Suite has already been used informally.  For completeness, you should
also mention "section" (main, contrib, non-free) in your more official
writeup.  You can sidestep the question whether sections besides main
are part of versions, releases or distributions. 8-)


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

Re: irc.debian.org

[Florian Weimer]

* Paul Johnson:

> Why not move it to Jabber?  More people use and know what Jabber is
> these days than IRC.

Really?  jabber.debian.net does not seem to accept new users.


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

Re: Oracle has a Debian repository now

[Florian Weimer]

* Michael Kallas:

> It would be a step into the right direction if Oracle would release it as
> Free Software (according to DFSG). Until then, I'm not sure how this is
> connected to the Debian project.

Debian officially supports non-free software, see the Social Contract
and .


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

Re: LWN subscription

[Florian Weimer]

* Isaac Clerencia:

> On Friday 10 March 2006 12:44, Steve Kemp wrote:
>> http://lists.debian.org/debian-devel-announce/2002/10/msg00018.html
> IIRC I did that

Me too, and IIRC the message is even stored in the corresponding
mailbox on master.  Is anybody still processing requests?


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

LWN subscription

[Florian Weimer]

Has Debian still got that blanket LWN subscription for all developers?


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

Re: Anfrage für Clan Sponsoring! www.quando-gaming.de

[Florian Weimer]

[He's asking if we might sponsor his computer gaming site.]

> Ich wollte Sie fragen ob Sie gerne unseren Clan Sponsern würden? 

Nein, Debian hat völlig andere Schwerpunkte.  Tut mir leid.

Re: Debian derivatives and the Maintainer: field (again)

[Florian Weimer]

* Matt Zimmerman:

> It is important, in particular, to account for the fact that Ubuntu is not
> the only Debian derivative, and that proposals like yours would amount to
> Debian derivatives being obliged to fork *every source package in Debian*
> for the sake of changing a few lines of text.

Such a change could be implemented in the toolchain.  IIRC, you
rebuild everything anyway, so this wouldn't be such a terrible thing
to do.

FWIW, I think your implied assumption that all Debian derivatives
should be treated the same is flawed.  Ubuntu is just not like any
other derivative, it's a significant operation on its own.  Its
commercial backer is apparently able to pay quite a few Debian
developers, several of them among the core team.  There is a
significant user base, and so on.  Like it or not, Ubuntu is a bit
special.


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