Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Julian Mehnle]

Kalle Kivimaa wrote:
> in my opinion the new [qmail] license is DFSG-free.

There ain't no new license.  DJB simply retracted his copyright.  As of 
now, anyone can copy the qmail 1.03 code, make modifications at will, 
claim copyright for those modifications, and distribute the whole under 
any license they wish (or none at all, contributing their modifications 
to the public domain as well).


signature.asc
Description: This is a digitally signed message part.

Bug#444443: ITP: net-dns-resolver-programmable-perl -- programmable DNS resolver class for offline emulation of DNS

[Julian Mehnle]

Package: wnpp
Severity: wishlist
Owner: Julian Mehnle <[EMAIL PROTECTED]>


* Package name: net-dns-resolver-programmable-perl
  Version : 0.003.1
  Upstream Author : Julian Mehnle <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Net-DNS-Resolver-Programmable/
* License : Perl (GPL-2 / Artistic)
  Programming Lang: Perl
  Description : programmable DNS resolver class for offline emulation of DNS

Net::DNS::Resolver::Programmable is a Net::DNS::Resolver descendant class that
allows a virtual DNS to be emulated instead of querying the real DNS.  A set
of static DNS records may be supplied, or arbitrary code may be specified as a
means for retrieving DNS records, or even generating them on the fly.


The source package would generate a libnet-dns-resolver-programmable-perl
binary package.



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

Bug#444442: ITP: mail-spf-perl -- Perl implementation of Sender Policy Framework and Sender ID

[Julian Mehnle]

Package: wnpp
Severity: wishlist
Owner: Julian Mehnle <[EMAIL PROTECTED]>


* Package name: mail-spf-perl
  Version : 2.005
  Upstream Author : Julian Mehnle <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Mail-SPF/
* License : BSD
  Programming Lang: Perl
  Description : Perl implementation of Sender Policy Framework and Sender ID

Mail::SPF is an object-oriented Perl implementation of the Sender Policy
Framework (SPF) e-mail sender authentication system <http://www.openspf.org>.

It supports both the TXT and SPF RR types as well as both SPFv1 (v=spf1) and
Sender ID (spf2.0) records, and it is fully compliant to RFCs 4408 and 4406.
(It does not however implement the patented PRA address selection algorithm
described in RFC 4407.)


The source package would generate two binary packages: libmail-spf-perl
and spf-tools-perl, the latter of which would ship the executables
included with the Mail::SPF upstream package (currently spfquery and
spfd).



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

Re: hijacking libhtml-mason-perl

[Julian Mehnle]

Charles Fry wrote:
> [...] I have already packaged the new upstream release of
> libhtml-mason-perl. 

Could you make the prepared package available for download in advance?  
That would be great!

Julian.


pgpUAPiI9FbmW.pgp
Description: PGP signature

RE: Problems with - and ' in some man-pages

[Julian Mehnle]

Thaddeus H. Black wrote:
> Eric Lavarde writes,
> > in some man pages ... the dashes and single quotes are
> > not really what they look like, but some other unicode
> > letter.  This has two major drawbacks:
> > - search for options become nearly impossible
> > ...
>
> You illustrate well the fundamental problem with
> indiscriminate use of a very large character set like
> Unicode.  If people want to use Unicode, this is fine;
> Unicode and utf-8 exist to be used, after all.  However,
> restricted character sets (mainly ascii and Latin-1)
> offer several real practical benefits that Unicode can
> never provide.  One such benefit is that dashes and
> single quotes are usually what they appear to be.
>
> Comprehensiveness is important, and Unicode is nothing
> if not comprehensive.  On the other hand, simplicity is
> a prime aesthetic, which Unicode lacks.

You might want to take a look at Bytext[1], an alternative approach to a design 
for a comprehensive character set.  For the Bytext
charset, implementing a search for classes of similar characters is almost 
trivial.

Anyhow, Bytext certainly is not going to replace Unicode for the foreseeable 
future, so any user interface search function that is
supposed to operate on Unicode text must be prepared to perform fuzzy searches 
if it does not want to be mostly useless.  Perhaps a
wishlist bug against "less" is due.

References:
 1. http://www.bytext.org


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

RE: charsets in debian/control

[Julian Mehnle]

Thaddeus H. Black wrote:
> However, the typical roster of skills one masters in contributing
> broadly to Debian development is already awesome: C, C++, CPP, Make,
> Perl, Python, Autoconf, CVS, Shell, Glibc, System calls, /proc, IPC,
> sockets, Sed, Awk, Vi, Emacs, locales, Libdb, GnuPG, Readline, Ncurses,
> TeX, Postscript, Groff, XML, assembly, Flex, Bison, ORB, Lisp, Dpkg,
> PAM, Xlibs, Tk, GTK, SysVInit, Debconf, ELF, etc.---not to mention the
> use of the English language at a sophisticated technical level.

Pardon me, but I only know 18 of the 40 items you mentioned, but I don't
have a problem writing software for Debian or Linux in general.

(Some) developers having to learn (parts of) Unicode is not a _general_
problem, not the least because many already know it.  It might be a
problem for _you_in_particular_, because you do not know it and don't want
to learn it.

But that isn't a very good argument against applying a perhaps somewhat
complex technology to Debian that's well suited for the job.  Especially
since many tools that today can't handle multibyte encodings
(UTF-8/Unicode in particular) yet, will _have_to_ support it at some time
in the future anyway.  BTW, the understanding of Unicode isn't required
for most tools, mostly the understanding of UTF-8 is sufficient, and UTF-8
is trivial.

> UTF-8 is neat, but I do not really like Unicode (you may have noticed
> this).

You might like Bytext[1] better then.  SCNR ;-)

Seriously, I get the impression you don't like Unicode because _you_ don't
need it.

> Seeking essential simplicity, I would prefer to keep the full hairy
> overgrown Unicode standard from the typical Debian roster of development
> skills.  Wouldn't you?

No, I wouldn't.

References:
 1. http://www.bytext.org

RE: charsets in debian/control

[Julian Mehnle]

Thaddeus H. Black wrote:
> I do not deny that Latin-1 represents all the languages I can read, and
> that this fact may color my view.  Nevertheless to me a source written
> in Chinese is effectively non-free.  It might as well be a compiled
> binary blob. 

So Emacs is effectively non-free, because I don't speak Lisp.

Heh, good one! ;-)

RE: GNU within the name (Was: Changes in formal naming for NetBSD porting effort(s))

[Julian Mehnle]

[EMAIL PROTECTED] wrote:
> If we ever get a replacement libc that would really work as
> replacement... on such system GNU claims would become much weaker.  Not
> that there was a serious chance of that happening - drop-in replacement
> of glibc on Linux would be a lot of work and so far none of the
> alternative libc projects had tried to pull that off.

Why would anyone want to replace GLIBC in the first place?  To get rid of "GNU" 
in "GNU/Linux"?

RE: Proposed change to debian release system

[Julian Mehnle]

Lucas Albers wrote:
> Julian Mehnle wrote:
> > I know this is no panacea, since in many cases, the maintainer cannot
> > know whether a package will perish at all (like when all spammers
> > promptly give up "advancing" their software, so a given version of
> > spamassassin would stay useful forever)... ;-)
> 
> My friend has a high volume mail server running spamassassin 2.31
> Oops the spamassassin stopped working.
> Now I have 12,000 people angry with me.
> Take that to the bank.

Lucas, not only did you horribly misquote my statement as coming from Scott, 
but you also seem to not having read my mail thoroughly.  Nowhere did I suggest 
that installed packages stop working when "expired", did I?  Please re-read my 
suggestion.

RE: Complaint

[Julian Mehnle]

Ingo Juergensmann wrote:
> Why people tend to become polemic when they have no arguments left?

Very good question.

Ingo Juergensmann wrote:
> Oh, great... I wouldnÂt have expected that getting polemic is a
> necessary to become DPL... :-//

So can we please end this flamewar before it really starts off?

RE: Proposed change to debian release system

[Julian Mehnle]

Scott Minns wrote:
> Thanks for your replyâs, I like the idea of making some packages
> "perishable" the trouble is where would you draw the line?

We could add an optional control field "Expires: $date" to packages, so package 
maintainers could decide for themselves.  After a package has expired, it would 
only be installed with a warning or even with the admin explicitly confirming 
he wants to install it anyway.

I know this is no panacea, since in many cases, the maintainer cannot know 
whether a package will perish at all (like when all spammers promptly give up 
"advancing" their software, so a given version of spamassassin would stay 
useful forever)... ;-)

RE: Bug#223781: [RFA]: usemod-wiki -- Perl-based Wiki clone

[Julian Mehnle]

Hi Peter,

Alexander Wirt wrote:
> Am Fr, den 12.12.2003 schrieb Julian Mehnle um 15:32:
> > Benjamin Drieu wrote:
> > > I no longer use usemod-wiki and thus have no time to maintain it.
> > > Package is in good shape, no serious bugs.  Very few work is needed
> > > to maintain it as release cycle is quite long.
> > > 
> > > The only one todo item is to package version 1.0, which requires
> > > some changes to the wiki database.  Peter Gervai <[EMAIL PROTECTED]>
> > > has already made a package for this and is going to NMU
> > > usemod-wiki.  But as he does not have time to adopt it, we need a
> > > new maintainer. 
> > 
> > As I'm using UseMod Wiki on a slew of Debian machines, I'd be more
> > than willing to continue maintaining usemod-wiki, but I'm no Debian
> > Developer, so I'd need a sponsor until I decide and manage to become
> > one. 
> 
> I use it on some systems too, so I would be pleased to be your sponsor.
> Get in touch with me if you have packages ready for upload/inspection.

Are you going to do an NMU wrt usemod-wiki 1.0?  If yes, are you going to 
include an automatic upgrade mechanism for old singlebyte Wikis?  If yes, I'll 
wait for that NMU before starting my own packaging work.

Otherwise, would you mind sending me whatever you have packaged up for 1.0, so 
I can add an automatic upgrade mechanism (which I'd really like to include with 
the initial release of the 1.0 Debian package)?

RE: Bug#223781: [RFA]: usemod-wiki -- Perl-based Wiki clone

[Julian Mehnle]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Benjamin Drieu wrote:
> I no longer use usemod-wiki and thus have no time to maintain it.
> Package is in good shape, no serious bugs.  Very few work is needed to
> maintain it as release cycle is quite long.
> 
> The only one todo item is to package version 1.0, which requires some
> changes to the wiki database.  Peter Gervai <[EMAIL PROTECTED]> has
> already made a package for this and is going to NMU usemod-wiki.  But
> as he does not have time to adopt it, we need a new maintainer.

As I'm using UseMod Wiki on a slew of Debian machines, I'd be more than
willing to continue maintaining usemod-wiki, but I'm no Debian Developer,
so I'd need a sponsor until I decide and manage to become one.

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.8
Comment: Get my PGP public key at .

iQA/AwUBP9nDXsC+zypQWVo7EQJJZACfUMiuM8Z19w/ydpwpnpnESmyHYkoAoMtY
bAopzElp8scS+9hcetlzhFfH
=gbCW
-END PGP SIGNATURE-

RE: Revocation list for old packages with security holes

[Julian Mehnle]

Goswin von Brederlow wrote:
> "Julian Mehnle" <[EMAIL PROTECTED]> writes:
> > We could use a revocation list where signatures of packages with
> > known security holes are listed as being revoked.  Of course, you'd
> > need to be online to check it when installing/updating packages.
> > And the revocation list would best be served from a server that's
> > secure and separate from the archive servers to make attacks against
> > it a bit more difficult.
> 
> And how do you make sure the revokation list isn't compromised (kept
> in the state it was a few days ago)? Its the same problem as with the
> Packages/Release.gpg files. 

The revocation list would need to be signed with a special private key that is 
stored on a non-networked machine.  It's not too often that signatures of old 
packages need to be revoked.  Probably mostly just whenever the security team 
releases a security-fixed package (of course also on some other occasions).

Of course, such a package revocation list brings all the problems that other 
types of revocation lists, e.g. SSL certificate revocation lists, have.  But as 
proven by VeriSign & Co., these problems can be successfully mastered.

> That the one (two) big argument for signed debs: ease of use and
> transparency. 

Not exactly.  Also, individual signed debs could be downloaded[1] and verified 
*individually*.  No need for Packages/Release.gpg files.

[1] E.g. from http://wiki.debian.net/?DebianKDE or 
http://people.debian.org/~$developer/

Revocation list for old packages with security holes (was: Re: Revival of the signed debs discussion)

[Julian Mehnle]

Joey Hess <[EMAIL PROTECTED]> wrote:
> Goswin von Brederlow wrote:
> > What can we do with deb signatures?
> >
> > For our current problem, the integrity of the debian archive being
> > questioned, the procedure would be easy and available to every user:
> >
> > 1. get any clean Debian keyring (or just the key signing the keyring)
> > 2. verify the latest Debian keyring
> > 3. verify that each deb was signed by a DD and the signature fits
>
> The canoical attack against signed debs in this situation is to find a
> signed deb on snapshot.debian.net that contains a known security hole.
> Now inject it into the compromised archive, with a changed filename, and
> edit the Packages file to have its md5sum. Now a user's checks will
> succeed -- the package is signed with a developer's key -- but they will
> install the old, insecure .deb. The only hint will be a warning from
> dpkg that it is downgrading the package, and a clever attacker might
> avoid even that.

We could use a revocation list where signatures of packages with known security 
holes are listed as being revoked.  Of course, you'd
need to be online to check it when installing/updating packages.  And the 
revocation list would best be served from a server that's
secure and separate from the archive servers to make attacks against it a bit 
more difficult.

> I would still like to be able to produce signed debs, it's another layer
> of security, but they are no panacea.

True.

RE: Backport of the integer overflow in the brk system call

[Julian Mehnle]

Russell Coker wrote:
> On Mon, 8 Dec 2003 23:14, "Julian Mehnle" <[EMAIL PROTECTED]> wrote:
> > You cannot verify the IP address *exactly*, but you can verify
> > whether the IP address lies within a range.  Dial-up users could at
> > least register a certain address range, so as to vastly mitigate the
> > attack risk.  Apart from that, as soon as the use of IPv6 broadens,
> > dynamically assigned IP addresses will diminish.
> 
> That will work in some situations, but not in all.

True.  But even though it might not prevent *all* attacks, it will prevent 
*many*, without incurring additional costs or adding considerable complexity to 
the Debian Developer apparatus, will it not?

RE: Backport of the integer overflow in the brk system call

[Julian Mehnle]

Russell Coker wrote:
> On Mon, 8 Dec 2003 13:16, Patrick Ouellette <[EMAIL PROTECTED]> wrote:
> > Instead of a smartcard/token/whatever physical device, this incident
> > could possibly have been thwarted by requiring developers to
> > pre-register their machine with the project (using ssh host key for
> > example).  The attacker would have the user's account information,
> > but project machines would have refused access since the host id did
> > not match the user's registered hosts.  Then the project machine
> > could have alerted both the project's admin team and the owner of the
> > compromised account. 
> 
> One problem with this is developer's machines that are on dial-up
> Internet connections.  In the case of such machines you can verify the
> host key but not the IP address.

You cannot verify the IP address *exactly*, but you can verify whether the IP 
address lies within a range.  Dial-up users could at least register a certain 
address range, so as to vastly mitigate the attack risk.  Apart from that, as 
soon as the use of IPv6 broadens, dynamically assigned IP addresses will 
diminish.

> But this still leaves the issue of how to deal with dial-up machines. 
> Even if we restrict connections to a single ISP as often dial-up
> machines are not used with multiple machines, this still isn't
> necessarily much good, some dial-up ISPs have >50,000 IP addresses.

Still, IP address (even if it's a range, not a single address) verification 
vastly mitigates the attack risk.

> Finally, if the attacker can compromise the machine and the machine is
> online (EG permanently connected machines) there's no good options.

What's more secure, "no good options", or "no good options" plus IP address 
verification, even if range-based?  Some attack vectors one will never be able 
to protect against, but it still makes sense to protect against other vectors, 
doesn't it?

RE: Backport of the integer overflow in the brk system call

[Julian Mehnle]

Andreas Schuldei wrote:
> * Russell Coker ([EMAIL PROTECTED]) [031203 04:03]:
> > I have sent a message to Werner asking if the GPG smart-card device
> > could be re-implemented with a USB interface.  I think that a USB
> > dongle with GPG technology would be a good option as most developer's
> > machines already have USB support.
> 
> as discussed in depth in an earlier c't magazine (german) usb is
> not a save bus to use for security relevant applications, since
> it allows for recording and backplaying of command sequences.

What article was that?

Anyhow, a serial port or a PS/2 keyboard port is "unsafe" in the same way.  A 
secure card reader solution would use a challenge/response procedure, so a 
simple replay attack could never be successful.  Additionally, a secure card 
reader device would be sealed (and deactivate/destroy itself upon physical 
break-in) and require the user to enter a PIN/password to use the cryptographic 
key stored on the card.  What would make such a card reader solution 
particularly unsafe when connected through USB?

RE: Tabs v.s. spaces (was Re: Programming first steps.)

[Julian Mehnle]

Steve Lamb wrote:
> 2: Can you provide an example of such free-style coding that you speak
> so highly of?

# Split header into separate header lines, dropping any unneeded or
# spurious header lines:
@header_lines = grep(
(
/^(?:
# Wanted headers:
X-Spam-Status
):/ix or
!/^(?:
# Unwanted headers:
Delivered-To|
Path|
Priority|
Received|
Return-Path |
(?: # Prefixes:
List|
X
)-[\w-]+
):/ix
),
split(/\n(?!\s)/, $header_unwrapped)
);

I call that readable, but I guess somebody won't. ;-)

RE: How to find all reverse depends of a package?

[Julian Mehnle]

Nathanael Nerode wrote:
> Without, that is, installing every package in Debian.
> 
> I'm curious, for instance, as to why emacs20 hasn't managed to be
> removed yet.  Presumably something depends on it.  But I can't figure
> out what. 

`apt-cache showpkg emacs20`

RE: debian-installer beta 1

[Julian Mehnle]

Henrique de Moraes Holschuh wrote:
> Just ditch the ataraid crap, the only use for it is to share raid arrays
> with MS Windows.

That was my point.  So I can't ditch the ATARAID crap.  Sorry.

RE: debian-installer beta 1

[Julian Mehnle]

Goswin von Brederlow wrote:
> Julian Mehnle <[EMAIL PROTECTED]> writes:
> > Is "md RAID" (I don't know this one) compatible with ATARAID in
> > regard of the partition/storage layout on disks, i.e. can I use
> > ATARAID drivers to access "md RAID" disks and vice versa?  I need
> > this kind of compatibility since I dual-boot Windows 2000 on the
> > systems in question. 
> 
> Of cause not. [...]

Thought so.  So, I'll reiterate my original statement:

Brian May wrote:
> I have tried debian-installer, and found it to be great!
> 
> I just have three feature requests, if they aren't already supported:
> [...]
> 3. Software raid support?

That would be great!  At least if it means ATARAID-style software RAID.  No 
opinion about LVM-style RAID.

;-)

RE: debian-installer beta 1

[Julian Mehnle]

Henrique de Moraes Holschuh wrote:
> On Sun, 16 Nov 2003, Julian Mehnle wrote:
> > That would be great!  At least if it means ATARAID-style
> > software RAID.  No opinion about LVM-style RAID.
> 
> Yuck (if by ATARAID you mean those PoS controllers from, e.g., Promise
> -- these are slow as a snail compared to md software RAID), and Yuck
> for LVM RAID too (slow, limited, cubersome).
> 
> Good software RAID is md raid :)  with LVM on top of it, of course. 
> LVM is a good thing, if you do it right and never bother with
> 'striping' on the LVM layer. Do it in the md RAID layer (or hardware
> layer, for that matter). 

Is "md RAID" (I don't know this one) compatible with ATARAID in regard of the 
partition/storage layout on disks, i.e. can I use ATARAID drivers to access "md 
RAID" disks and vice versa?  I need this kind of compatibility since I 
dual-boot Windows 2000 on the systems in question.

PS: Please don't CC me when answering to the list.  The "Reply-To" header is 
just there for private replies.

RE: debian-installer beta 1

[Julian Mehnle]

Brian May wrote:
> I have tried debian-installer, and found it to be great!
> 
> I just have three feature requests, if they aren't already supported:
> [...]
> 3. Software raid support?

That would be great!  At least if it means ATARAID-style software RAID.  No 
opinion about LVM-style RAID.

RE: ftpmaster accepts packages that have been rejected a few days ago

[Julian Mehnle]

Mark Brown wrote:
> On Tue, Nov 11, 2003 at 08:18:51AM +0100, Marc Haber wrote:
> > Even if this is not a personal issue of Mr. Troup towards me, having
> > ftpmaster behave like A today and like B tomorrow is a bad thing. If I
> 
> There's more than one person behind ftpmaster.

Obviously, he knows that:

Marc Haber wrote:
> Even if this is not a personal issue of Mr. Troup towards me, having
> ftpmaster behave like A today and like B tomorrow is a bad thing. If I
> had a chance of knowing beforehand if a package uploaded will be
> handled by Mr. Troup or somebody else, there would be a chance of
> being handled fairly, but if the ftpmasters obviously don't
> communicate with each other [...]

RE: A case study of a new user turned off debian

[Julian Mehnle]

Greg Stark <[EMAIL PROTECTED]> wrote:
> [...]

First, I think what Daniel Jacobowitz said is entirely true.  Why didn't you 
start with "testing"?

> All he had to do was install an older version of libc6 and every other
> package would have been happy. All the infrastructure is there to do
> this, the old packages are all on the ftp/http sites, the package may
> even be sitting in apt's cache. But there's no interface for it.

Wrong.  If, on a "unstable" system, Apt sources for "testing" are also listed 
in /etc/apt/sources.list, you can always do a `apt-get -t testing install 
libc6` or `apt-get install libc6/testing`.

Or, you could create a file /etc/apt/preferences and pin the "testing" version 
of the package with a high enough priority.  See `man apt_preferences`.  Then 
do a `apt-get dist-upgrade`.

> The only interface for rolling back is switching the entire machine to
> an earlier distribution and telling apt to try to downgrade -- which is
> unlikely to work. And worse, every time you run apt it only downloads
> and unpacks *more* packages, all of which, of course, fail as well.

This is probably one of the worst ways of rolling back few or even a single 
package.

RE: recent spam to this list

[Julian Mehnle]

Kris Deugau wrote:
> > > OK, I think I've thought of a sort of a counter-example: [...]
> > > I'm sending "from" myfriendsdomain.com's server, but I don't have an
> > > account there. I do, however, have an account [EMAIL PROTECTED]
> > > on my own server- to which I want all replies/bounces/etc to go to.
> 
> [...]
> IIRC the original question was answered to the satisfaction of the
> person who asked it.  Listing the servers allowed to send mail "from"
> your domain, as a part of your DNS, makes perfect sense to me...  "all"
> you have to do is track down the IPs of those machines.  

Alternatively, you could still use <[EMAIL PROTECTED]> as the envelope-from 
when sending from *anywhere* -IF- you send through mailserver.mydomain.com 
using SMTP-Auth.

RE: recent spam to this list

[Julian Mehnle]

Kris Deugau wrote:
> Julian Mehnle wrote:
> > Andreas Metzler wrote:
> > > If I send an e-mail over mail.nusrf.at with envelope-from
> > > [EMAIL PROTECTED] I am _not_ forging anything or making
> > > "unauthorized use of domains"
> > 
> > Yes, you are.  The envelope-from address is not a reply-to address,
> > it's a sender address.  If you are sending from mail.nusrf.at, you
> > are not sending from logic.univie.ac.at.  So you should not specify
> > <[EMAIL PROTECTED]> as the envelope-from address, or you'd
> > be forging it.
> 
> OK, I think I've thought of a sort of a counter-example:
> 
> 
> [...]
> I'm sending "from" myfriendsdomain.com's server, but I don't have an
> account there.  I do, however, have an account [EMAIL PROTECTED] on
> my own server- to which I want all replies/bounces/etc to go to.
>  

Why don't you use <[EMAIL PROTECTED]> as the envelope-from and <[EMAIL 
PROTECTED]> as the "From:" header field?  Replies will go to <[EMAIL 
PROTECTED]>, while bounces will go to <[EMAIL PROTECTED]>.  If your friend's 
server is configured correctly, it won't send out-of-band bounces (bounces as 
stand-alone messages, instead of a bounce reply code in the SMTP dialog) to 
foreign (non-local) servers anyway (to mitigate joe jobs on innocent bystanders 
whose address was used as some spam's envelope-from).

> I'm not sure this actually has any direct relevance to this dicussion
> (which I gather is about a DNS-ish way to restrict which machines can
> relay mail for any particular domain, according to the wishes of that
> domain owner), but I think it might be a useful example.

Sure, it is relevant.

RE: recent spam to this list

[Julian Mehnle]

John Hasler wrote:
> Joel Baker writes:
> > If adding .1 to your SA score for lacking a repudiation protocol, and
> > 3 (or 5, or whatever) for claiming to be from a domain that denies
> > that it origionates mail to the rest of the world from your IP...
> 
> I have no IP.  Outgoing mail from home goes via my ISP's smarthost.
> Incoming mail goes to his POP server.

Consider your ISP's smarthost's IP address "your IP".  It makes no difference.

> > If lacking a domain-authorized relay point comes to eventually have
> > the same statistics, you'd better bet that you'll have the same sorts
> > of penalties in spamfilters.
> 
> What do you mean by "a domain-authorized relay point"?  It was my
> understanding that the idea behind SPF was that I would list in the DNS
> for my domain the IPs that were authorized to send mail claiming to
> be from my domain.  That would be fine with me, but I evidently
> misunderstood.

No, you understood it correctly.  That's exactly the point.

RE: recent spam to this list

[Julian Mehnle]

John Hasler wrote:
> Julian Mehnle writes:
> > No, but this again is one of these broken "e-mail vs. real world"
> > analogies.  You can't receive mail through such a letter box, but a
> > sender address is inherently meant to be a valid address through which
> > you can be contacted (among other criteria).
> 
> I can no more be contacted via the machine in that library than I can via
> the letterbox.  I go in there, spend five minutes sending an email and
> leave, expecting any replies or bounces to go to my real address.  If my
> message is bounced to that box or a reply sent there it will vanish
> without a trace.

Then it's up to the library to decide whether to offer this feature 
(envelope-from forgery, or call it envelope-from pretendery) or protect its 
domain from unauthorized use in envelope-froms.  Of course the latter option 
implies restrictions for users like you, but the library is not at all required 
to implement these restrictions for its domain.

I still don't understant why so many people object against the cited 
proposals...  The implementation on the sending side (i.e. the DNS 
configuration) is entirely optional.

RE: recent spam to this list

[Julian Mehnle]

John Hasler wrote:
> Julian Mehnle writes:
> > It does very well make sense to specify a "sender address" for an
> > e-mail, and that's exactly what the SMTP "MAIL FROM" command AKA
> > envelope-from (and the "Sender:" header) is meant to be.  Even RFCs
> > (2)821 and (2)822 articulate it that way.  Nowhere do these RFCs state
> > that the envelope-from can or should be used for status reporting
> > *only*, do they? 
> 
> If I go to Eau Claire and drop a letter in a letter box am I required to
> put the address of the box on the letter?

No, but this again is one of these broken "e-mail vs. real world" analogies.  
You can't receive mail through such a letter box, but a sender address is 
inherently meant to be a valid address through which you can be contacted 
(among other criteria).

Sender address forgery is not a serious problem with snail mail, but it is with 
e-mail.  And with e-mail, it is possible to do things that are hardly possible 
with snail mail, e.g. checking the authenticity of the sender address.  An 
e-mail's sender address domain should (in this regard) better be compared to 
the stamp of the post office where the letter was accepted.

> How about if I go into a library in Eau Claire and send an email?  Why
> should I not put my Elmwood address on it?

You may put your Elmwood address into the From: or Reply-To: fields, but should 
not specify it as the envelope-from.

> Of what possible use to anyone would the address of the machine I sent
> it from be?

If the sender address (envelope-from) of an e-mail was unforgeable (for a given 
domain), the sender would be guaranteed to have an account at this domain (and 
be it only to *send* mail), and any abuse could be reliably traced back to the 
sender's account (not just to the sending host).  That's what address forgers 
fear.

RE: recent spam to this list

[Julian Mehnle]

Michael Poole wrote:
> Julian Mehnle writes:
> > Don't you agree on my understanding of a sender address (or source
> > mailbox) being the address (or source mailbox) the sender sends
> > from?  If so, please state it explicitly, so I have something I can
> > argue against. :-)
> 
> Mail is not sent from any particular address at all; it is sent by a
> person or program.  It is delivered to one or more addresses.  The
> From: address and SMTP and envelope sender addresses are for human
> understanding and status reporting.

It does very well make sense to specify a "sender address" for an e-mail, and 
that's exactly what the SMTP "MAIL FROM" command AKA envelope-from (and the 
"Sender:" header) is meant to be.  Even RFCs (2)821 and (2)822 articulate it 
that way.  Nowhere do these RFCs state that the envelope-from can or should be 
used for status reporting *only*, do they?

> Forgery generally means to create written authorization that shows
> false provenance.

No.  You can also forge paintings as well as originator address specifications 
and other information.  Call it counterfeiting, but essentially it's the same 
thing.

> A user who indicates status messages should go to his own address is
> not forging that address, even if it is not an obvious address given
> the user's hostname.

Agreed, but a user indicating a "MAIL FROM: <[EMAIL PROTECTED]>" while sending 
from a host in the "bar.org" domain is forging the "MAIL FROM" address.

> It probably is useful to perform checks on those addresses, to verify
> that the administrator of the domain allows the sender to claim an
> identity under the domain.  If such an authorization check fails,
> forgery is just one possible explanation.

Generally true, but in part it depends on how you define "forgery".

RE: recent spam to this list

[Julian Mehnle]

Andreas Metzler wrote:
> On Mon, Oct 13, 2003 at 02:47:44PM +0200, Julian Mehnle wrote:
> > There you have it.  It's the "source mailbox", and while it can be
> > used to report errors, it can *not only* be used to report errors.
> > I'm relieved that the RFC doesn't contradict my common sense
> > understanding of a "sender address".
> 
> I does not confirm it.

Confirm what?  My common sense understanding of a sender address?  Hopefully 
RFCs wouldn't have to define *everything* they relate to, since common sense 
already defines a lot of it.

Don't you agree on my understanding of a sender address (or source mailbox) 
being the address (or source mailbox) the sender sends from?  If so, please 
state it explicitly, so I have something I can argue against. :-)

> There is no such thing as "the domain part of the 
> should/has to/must be identical to the domain name of the machine the
> mail was written on originally", it just states that 
> can be used to report errors to.

RFC 2821 may not state that.  So the cited proposals (like SPF, etc.) were 
created as proposed amendments to RFC 2821, and *they* do demand that -- for 
domains that have been configured that way, not for other domains.  So where do 
you see a problem?

RE: recent spam to this list

[Julian Mehnle]

Andreas Metzler wrote:
> Julian Mehnle <[EMAIL PROTECTED]> wrote:
> > Andreas Metzler wrote:
> > > If I send an e-mail over mail.nusrf.at with envelope-from
> > > [EMAIL PROTECTED] I am _not_ forging anything or making
> > > "unauthorized use of domains"
> > 
> > Yes, you are.  The envelope-from address is not a reply-to address,
> > it's a sender address.  If you are sending from mail.nusrf.at, you
> > are not sending from logic.univie.ac.at.  So you should not specify
> > <[EMAIL PROTECTED]> as the envelope-from address, or you'd
> > be forging it.
> 
> No, I am just specifying where I want bounces to go to.
> 
>   MAIL FROM: [SP  ] 
> 
>This command tells the SMTP-receiver that a new mail transaction is
>starting and to reset all its state tables and buffers, including any
>recipients or mail data.  The  portion of the first or
>only argument contains the source mailbox (between "<" and ">"
>brackets), which can be used to report errors.

There you have it.  It's the "source mailbox", and while it can be used to 
report errors, it can *not only* be used to report errors.  I'm relieved that 
the RFC doesn't contradict my common sense understanding of a "sender address".

RE: recent spam to this list

[Julian Mehnle]

Tollef Fog Heen wrote:
> * Riku Voipio
> > Second hint: If you insist on your right to forge your email address,
> > anyone else can forge your address as well. Is that a right you really
> > need?
> 
> Uhm, how would you forge your own mail address?  It's like forging
> your own signature, something which is, by definition not possible:

A sender address, which the envelope-from is, is neither a signature nor an 
identity token (although it's often abused as such).  It's an address.  As I 
already responded[1] to Andreas Metzler a few minutes ago, it's very well 
possible to forge a sender address.

> > Third hint: You can still choose to allow any IP send emails in your
> > domains name. Just do not add the records in dns, and everything will
> > stay as it is currently.
> 
> No, I can't.  I don't control the DNS of my University, a few of my
> ISPs and so on.  Nor do I control Debian's DNS.

Although Debian might not want it, maybe that's exactly what the University 
wants.  Maybe they want you to use their mail server to send mails when using 
their domain in the sender address, so they have control over how the service 
"e-mail" is used "under their domain".

And everyone please stop making broken "e-mail vs. real world" analogies.

[1] <[EMAIL PROTECTED]>

RE: recent spam to this list

[Julian Mehnle]

Andreas Metzler wrote:
> Julian Mehnle <[EMAIL PROTECTED]> wrote:
> > It's about forging an e-mail sender's identity.  By preventing the
> > unauthorized use of domains as the sender domain of e-mails, most of
> > the practiced cases of identity forgery are prevented. [...]
> 
> If I send an e-mail over mail.nusrf.at with envelope-from
> [EMAIL PROTECTED] I am _not_ forging anything or making
> "unauthorized use of domains"

Yes, you are.  The envelope-from address is not a reply-to address, it's a 
sender address.  If you are sending from mail.nusrf.at, you are not sending 
from logic.univie.ac.at.  So you should not specify <[EMAIL PROTECTED]> as the 
envelope-from address, or you'd be forging it.

RE: recent spam to this list

[Julian Mehnle]

(Andreas, please excuse the accidental CC!)

Andreas Metzler wrote:
> Julian Mehnle <[EMAIL PROTECTED]> wrote:
> > Convince the owner of these domains that you are (that is, your
> > outgoing mail server is) allowed to send mail "from these domains".
> 
> Think "these domains" = debian.org and "outgoing mail server" = every
> smarthost that is provided by an internet access provider around the
> globe. 
> 
> You either end up with publishing records for @debian.org that allow
> any server to send with MAIL FROM:[EMAIL PROTECTED] (no gain, that is
> exactly what we have currently) or force people to route their mail by
> sender, i.e. manually.

By none of the mentioned proposals is every domain required to restrict the set 
of allowed sending hosts.  Every domain owner who doesn't want that restriction 
for his domain may very well ignore these proposals.

RE: recent spam to this list

[Julian Mehnle]

(Bernhard, please excuse the accidental CC!)

Bernhard R. Link wrote:
> * Riku Voipio <[EMAIL PROTECTED]> [031012 20:25]:
> > Second hint: If you insist on your right to forge your email address,
> > anyone else can forge your address as well. Is that a right you really
> > need?
> 
> It's about to *use* an e-mail address, not about forging one...

It's about forging an e-mail sender's identity.  By preventing the unauthorized 
use of domains as the sender domain of e-mails, most of the practiced cases of 
identity forgery are prevented.

> [...] I'm against this proposal [...]

Does this have a reason?  And if yes: which?

RE: recent spam to this list

[Julian Mehnle]

Tollef Fog Heen wrote:
> * Gerfried Fuchs
> > The concept of SMTP AUTH is completely new to you, is it? Sorry,
> > these kind of objections are just as silly as you call the proposal
> > silly. 
> 
> Uhm, no, why should it be?  Having gnus set up to use SMTP auth and
> using a different server based on what the From address is would suck
> and be non-trivial. 

Oh, come on!  Even Outlook supports that.

> How would you set up so that my laptop (or yours or whoever's) can
> send mail from about ten different domains if the server you are
> sending to is using SPF and the domain you are sending from have it
> implemented in DNS? 

Convince the owner of these domains that you are (that is, your outgoing mail 
server is) allowed to send mail "from these domains"?

RE: IMPORTANT: your message to html-tidy

[Julian Mehnle]

Karsten M. Self  wrote:
> [Using DNS RBLs to block spam is bad.]
> As many people have noted, for pretty much _any_
> given IP, your odds are good that most of the mail received from it is
> spam.  It doesn't do much for the legit mail that comes through.  Given
> that we now _do_ have good content/context based filters for assessing
> spam likelihood for a given mail item, blind use of RBLs should be
> discouraged.  It's the same sort of thinking that's causing no end of
> trouble for people trying to communicate with AOL users:
> 
> http://z.iwethey.org/forums/render/content/show?contentid=96264
> http://yro.slashdot.org/yro/03/04/13/2215207.shtml?tid=120

No, you can't make such a general statement that using content-based filters is 
"better" than using DNS RBLs.  It wholly depends on the listing policy of the 
RBL, and in most cases, content-based filters will be the far worse option, 
because it only drives spammers to make their spam stick out from the general 
mail noise less and less!  I.e. after prolonged, widespread use of 
content-based filters, spam won't be easily distinguishable from your normal 
mail traffic anymore from a machine's point of view.

Maybe in 50 years, when machines will be able to (almost) fully understand the 
content of a mail message, this will be a good solution.  But until then, I 
consider a well-designed DNS RBL like bl.spamcop.net to be far superior, even 
if it causes a few (<0.02% for me, in the SpamCop case) false positives now and 
then (the SpamCop list even puts up with these by design).  If configured 
correctly, false positives, like all positives, get bounced in the SMTP dialog, 
so the sender knows that the message wasn't delivered.

> The difference between what I'm advocating and what you're doing:  run
> SpamAssassin _at_ _SMTP_ _receipt_, not after accepting the message for
> delivery.  Exim4 allows this readily.

Indeed.  Bouncing in the SMTP dialog is by far preferrable to bouncing after 
accepting the message.  In fact, the latter method is inacceptable in 95% of 
all cases (except for when the delivery failure could not have been determined 
at the time the message was accepted).  And even in the remaining cases, it 
might be better to silently drop the message.

RE: Bits from the RM

[Julian Mehnle]

cobaco <[EMAIL PROTECTED]> wrote:
> On 2003-08-20 15:33, John Goerzen wrote:
> > tne pain of breaking desktops is no less when
> > you consider how many more desktops we're talking about here.
> 
> that's assuming that all those desktops crash at the same time no?

No, it's assuming that all those desktops crash with the same average frequency 
(probability) per duration.

Consider one s = 1 company server serving c = 1000 clients (used by one user 
each).  Let's assume any one instance of a server software (e.g. Apache) 
crashes with a probability p_crash = 1% at any given time (i.e. it's down 1% of 
the time assuming a zero recovery time), and any one instance of a client 
software (e.g. Mozilla) does the same.  Now the expected number of users 
u_affected who can't use the company's intranet at any given time is...

...due to server failures:

  s * p_crash * u_aff,s = 1 * 0.01 * 1000 = 10

...due to client failures:

  c * p_crash * u_aff,c = 1000 * 0.01 * 1 = 10

(Of course, these sets of users do overlap, but that's not relevant here.)

So, assuming an equal crashing probability (AKA stability) of server and client 
software, "the pain of breaking desktops is no less" than the pain of breaking 
servers.  qed.

RE: Work-needing packages report for Jul 11, 2003

[Julian Mehnle]

Steve Greenland wrote:
> Or perhaps we should just decree that no unmaitained packages go out
> in a stable release. At the beginning of the freeze, mark all the WNPP
> packages for removal (along with their dependencies :-)), and then see
> if we can inspire some reaction.

Good idea!  An even better idea would be to remove packages from "testing" if 
they're orphaned for >6 months.

RE: debootstrapping and sysvinit

[Julian Mehnle]

Miquel van Smoorenburg wrote:
> Julian Mehnle <[EMAIL PROTECTED]> wrote:
> > Miquel van Smoorenburg wrote:
> > > And you think an attitude like this is going to make me work
> > > harder? For *you* ?? Get real.
> >
> > Regardless of whether it was right to NMU sysvinit without you being
> > notified:  I get the impression maybe you should think over why you have
> > accepted maintainership of the package.  If you are maintaining it for
> > your own sake only, then maybe you should give up maintainership and
> > use a self-maintained, forked copy of the package.
>
> I accepted maintainership because I am the upstream author, and having
> the package in Debian/unstable is a great way to make sure it is
> stable. I can also try out new features, and Debian will have it first.

Please excuse my ignorance of not recognizing you as the upstream author.
Your statement above made me feel like you had no real interest in keeping
the package working for everyone else.  I'm sorry!

Julian.

RE: debootstrapping and sysvinit

[Julian Mehnle]

Miquel van Smoorenburg wrote:
> Tobias Wolter wrote:
> > I still haven't seen any bugfix from you. How about you go stop
> > ranting about being treated unfair and DOING YOUR WORK?
>
> And you think an attitude like this is going to make me work
> harder? For *you* ?? Get real.

Regardless of whether it was right to NMU sysvinit without you being
notified:  I get the impression maybe you should think over why you have
accepted maintainership of the package.  If you are maintaining it for your
own sake only, then maybe you should give up maintainership and use a
self-maintained, forked copy of the package.

No offense,
Julian.

RE: Counter-Proposal: Architecture Versions and Architecture Features

[Julian Mehnle]

Andreas Barth wrote:
> * Julian Mehnle ([EMAIL PROTECTED]) [030627 21:05]:
> > [...]
> 
> Thanks for your proposal. IMHO it is important that we are going to
> adopt one or the other proposal rather soon, so that it could be used in
> sarge. 

I agree.

> Now to comments:
> 
> > Every base arch (alpha, i386, mips, ...) can, but isn't required to,
> > have one or more explicit versions (as I said, these are equivalent to
> > sub-archs). [...] Arch versions are ordered
> > alphabetically, with higher versions including the functionality of all
> > lower versions, i.e. higher arch versions must be downwards compatible.
> > Example: "i386" = "i386.0" < "i386.1" < "i386.1foo" < "i386.2".
> 
> The problem with this is: It works only if all relevant processor
> makes can be seen as a chain by inclusion, i.e. there is only one heir
> to each processor version. However, with AMDs Opteron on one side and
> the certainly next Intel processor on the other side there will be two
> "childs" with different features, so this fails. You can of course make
> it with  
> 
> > Independently, every arch can, but isn't required to, have one or more
> > special features beyond what the base arch version supports.
> 
> ... but this has the disadvantage of being unexact. What to do if a
> processor has three features, but in the special case the packages
> allows only two of them at a time?

No package is required to support any arch features at all.  If a package
just supports (i.e. requires) two arch features, while the actual arch
supports (i.e. provides) these plus an additional feature, one feature just
isn't going to be used by the package -- so what?  The package might not be
running as fast as possible, but it will work.  Just in case it wasn't
clear: it's up to the package maintainer to decide which arch version/
feature combos to build the package for.

> Or to make it worse say processor A
> supports maximum subarch 7, and feature A, but feature A can only be
> used really fast in subarch 6; packages in subarch 7 must also be
> built because they are faster on processors without feature A?

Are you implying that feature A will run slower on arch version 7 than on
arch version 6?  Even if that were the case, the package maintainer could
just build one binary package for arch.6+A and one for arch.7 (no A
feature).  It would then be up to the arch.7 system's administrator to
disallow the installation of +A packages by specifying his system to be
arch.7 only instead of arch.7+A (and this could as well be the global
default for arch.7+A systems).

I fear I don't entirely understand the scenarios you are portraying here.
I think there is no special-build case that can be handled by your proposal
but not by mine.  If you know one, please name it, maybe I'm just to tired
to see it.

> In your proposal one is bound to suboptimal matches in special cases,

Which ones?  Following my proposal, you are never forced to build any binary
packages beyond the base arch (e.g. plain "i386") package, but you may build
binary packages for any or all possible arch version/feature combos if you
want.

> and even a very good package maintainer can't get around. The argument
> that special cases are seldom won't match here because: The whole
> subarch-system is only needed in special cases. I don't believe that
> vi will get substantial speed improvements because of subarch specific
> versions (otherwise show me figures). ;-)

My proposal doesn't force the building of any special-build binary packages
beyond the base arch package, and most packages (e.g. vi) will just have
this one base arch package.  I'm certainly not preaching that vi would
benefit substantially from specialized builds. ;-)

> Because of this in my proposal exact matches are possible. There is
> only one case where unexact must be used, and this is when a new subarch
> comes to existence. 
> 
> The subarch information that could be stored in your modell can be
> also be stored in my modell, but also more complex information.

I don't see how.  In fact, I think our models are equivalent regarding the
representable set of (sub-)architectures, but my model is more structured.

You are suggesting opaque, black-box-like (from the user's point of view)
sub-arch tags which apt and dpkg would be required knowing how to handle.
So you'd need to provide some data structures that explain to apt and dpkg
how, for instance, i386_i586 differs from i386_i586-mmx so they know that a
i386_i586 binary package would be an acceptable fallback for a i386_i586-mmx
system, but not the other way round.

My proposal does part of that work by breaking down the opaqueness into 

Counter-Proposal: Architecture Versions and Architecture Features

[Julian Mehnle]

Hi all,

(I'm sending this message again, since the copy I sent yesterday seems not
to have made it onto the list.  If you receive it twice, please excuse.)

Andreas Barth wrote:
> DRAFT - Subarchitectures for debian [0.1]

First, thanks for creating a prototype proposal.

I understand that the your proposed extensions to the Debian package system
are based on the concepts of "sub-archs" and "meta-sub-archs" (I'd call
these "pseudo-sub-archs" or "alias-sub-archs", though).  I have already
proposed a more genereal extension based on "arch versions" (essentially
equivalent to sub-archs, except that an order is implicitly defined), and
"features".  I'll explain it in more detail, because I think that a more
general approach would also be more flexible for potential future
requirements in the Debian package system.


Architecture Specifiers
---

An arch specifier may specify the exact base arch, arch version, and arch
features that are supported by a given system, or that are required for a
given binary package to work (with or without an emulating kernel).

Every base arch (alpha, i386, mips, ...) can, but isn't required to, have
one or more explicit versions (as I said, these are equivalent to
sub-archs).  An arch version gets appended to the base arch name as
".", the default version being 0.  Thus, "i386" would be
equivalent to "i386.0", and subsequent versions could be "i386.1",
"i386.1foo", "i386.2", and so on.  Arch versions are ordered
alphabetically, with higher versions including the functionality of all
lower versions, i.e. higher arch versions must be downwards compatible. 
Example: "i386" = "i386.0" < "i386.1" < "i386.1foo" < "i386.2".

Independently, every arch can, but isn't required to, have one or more
special features beyond what the base arch version supports.  A feature
gets appended to the arch name/version as "+".  For "i386", there
could be features like "fpu", "mmx", "sse", "sse2", etc.  A single arch
specifier can name any number of features, e.g. "i386+3dnow", or
"i386.6+mmx+sse".


Binary Package Files


Binary package files shall have the full arch specifier in their file names
(see below for examples).  Current packages with simple (traditional) arch
specifiers such as "i386" don't require special features beyond what the
base arch version supports, thus the extension is backward compatible.


"control" and "Packages" Files
--

In "control" files, the "Architecture:" field, as before, lists the
architectures supported by the base arch binary packages.  Additionally,
more specific arch specifiers can be listed here.  Binary packages will be
built for every listed arch specifier.  Example:

  Architecture: alpha i386 i386.6+mmx+sse mips

The special "any" arch specifier in the "control/Architecture:" field would
only build binary packages for the base archs.

The "Packages" file of a given base arch would, for every binary package
based on (but of course not neccessarily supporting) that base arch, list
the packages' exact arch specifiers in the "Architecture:" field.  I.e.
although a binary package compiled for "i386.6+mmx+sse" probably will not
run on a real 80386 or Pentium 1 machine (disregarding any emulating
kernels), it will be part of the "i386" base arch nonetheless.


apt and dpkg


There might be several methods for apt and dpkg how to choose which
packages to download and to install.  Generally, binary packages for the
plain base arch will be downloaded and installed unless specified
otherwise.

The 'APT::Architecture' configuration option would specify the *minimum*
arch version and features that must be required by any package to be
installed.  The *maximum* arch version and features supported by the local
system could be configured either as some 'APT::Architecture-Maximum'
configuration or '--arch' command-line option, or as some generic
'/etc/hwarch' config file, or it might even be possible to query the kernel
for this information.

Apt would then choose the binary package compiled for the highest
compatible arch version and the most matching arch features that fulfills
both the minimum and maximum requirements.

Examples:

  Available packages in the fictitious pool:
  (A) pool/contrib/q/quake2/quake2_0.2.1-4_i386.deb
  (B) pool/contrib/q/quake2/quake2_0.2.1-4_i386.5+mmx.deb
  (C) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+3dnow.deb
  (D) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+mmx.deb
  (E) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+sse.deb
  (F) pool/contrib/q/quake2/quake2_0.2.1-4_i386.7+mmx+sse.deb
  (G) pool/contrib/q/quake2/quake2_0.2.1-4_i386.7+mmx+sse2.deb

  # uname -a
  Linux gray 2.4.20 #1 Fri Apr 4 14:43:45 CEST 2003 i686 GNU/Linux
  # cat /etc/apt/apt.conf
  APT::Architecture "i386";# minimum arch specifier
  APT::Architecture-Maximum "i386.6+mmx+sse";  # maximum arch specifier

  # apt-get install quake2
  (chooses package D, acceptable fallbacks 

Counter-Proposal: Architecture Versions and Architecture Features

[Julian Mehnle]

Hi all,

Andreas Barth wrote:
> DRAFT - Subarchitectures for debian [0.1]

First, thanks for creating a prototype proposal.

I understand that the your proposed extensions to the Debian package system
are based on the concepts of "sub-archs" and "meta-sub-archs" (I'd call
these "pseudo-sub-archs" or "alias-sub-archs", though).  I have already
proposed a more genereal extension based on "arch versions" (essentially
equivalent to sub-archs, except that an order is implicitly defined), and
"features".  I'll explain it in more detail, because I think that a more
general approach would also be more flexible for potential future
requirements in the Debian package system.


Architecture Specifiers
---

An arch specifier may specify the exact base arch, arch version, and arch
features that are supported by a given system, or that are required for a
given binary package to work (with or without an emulating kernel).

Every base arch (alpha, i386, mips, ...) can, but isn't required to, have
one or more explicit versions (as I said, these are equivalent to
sub-archs).  An arch version gets appended to the base arch name as
".", the default version being 0.  Thus, "i386" would be
equivalent to "i386.0", and subsequent versions could be "i386.1",
"i386.1foo", "i386.2", and so on.  Arch versions are ordered
alphabetically, with higher versions including the functionality of all
lower versions, i.e. higher arch versions must be downwards compatible. 
Example: "i386" = "i386.0" < "i386.1" < "i386.1foo" < "i386.2".

Independently, every arch can, but isn't required to, have one or more
special features beyond what the base arch version supports.  A feature
gets appended to the arch name/version as "+".  For "i386", there
could be features like "fpu", "mmx", "sse", "sse2", etc.  A single arch
specifier can name any number of features, e.g. "i386+3dnow", or
"i386.6+mmx+sse".


Binary Package Files


Binary package files shall have the full arch specifier in their file names
(see below for examples).  Current packages with simple (traditional) arch
specifiers such as "i386" don't require special features beyond what the
base arch version supports, thus the extension is backward compatible.


"control" and "Packages" Files
--

In "control" files, the "Architecture:" field, as before, lists the
architectures supported by the base arch binary packages.  Additionally,
more specific arch specifiers can be listed here.  Binary packages will be
built for every listed arch specifier.  Example:

  Architecture: alpha i386 i386.6+mmx+sse mips

The special "any" arch specifier in the "control/Architecture:" field would
only build binary packages for the base archs.

The "Packages" file of a given base arch would, for every binary package
based on (but of course not neccessarily supporting) that base arch, list
the packages' exact arch specifiers in the "Architecture:" field.  I.e.
although a binary package compiled for "i386.6+mmx+sse" probably will not
run on a real 80386 or Pentium 1 machine (disregarding any emulating
kernels), it will be part of the "i386" base arch nonetheless.


The Package Pool


Binary packages built for an explicit (non-base) arch version, or requiring
special features, like the fictitious "quake2" package mentioned below,
would be stored in the pool normally.  
base arch's pool.


apt and dpkg


There might be several methods for apt and dpkg how to choose which
packages to download and to install.  Generally, binary packages for the
plain base arch will be downloaded and installed unless specified
otherwise.

The 'APT::Architecture' configuration option would specify the *minimum*
arch version and features that must be required by any package to be
installed.  The *maximum* arch version and features supported by the local
system could be configured either as some 'APT::Architecture-Maximum'
configuration or '--arch' command-line option, or as some generic
'/etc/hwarch' config file, or it might even be possible to query the kernel
for this information.

Apt would then choose the binary package compiled for the highest
compatible arch version and the most matching arch features that fulfills
both the minimum and maximum requirements.

Examples:

  Available packages in the fictitious pool:
  (A) pool/contrib/q/quake2/quake2_0.2.1-4_i386.deb
  (B) pool/contrib/q/quake2/quake2_0.2.1-4_i386.5+mmx.deb
  (C) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+3dnow.deb
  (D) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+mmx.deb
  (E) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+sse.deb
  (F) pool/contrib/q/quake2/quake2_0.2.1-4_i386.7+mmx+sse.deb
  (G) pool/contrib/q/quake2/quake2_0.2.1-4_i386.7+mmx+sse2.deb

  # uname -a
  Linux gray 2.4.20 #1 Fri Apr 4 14:43:45 CEST 2003 i686 GNU/Linux
  # cat /etc/apt/apt.conf
  APT::Architecture "i386";# minimum arch specifier
  APT::Architecture-Maximum "i386.6+mmx+sse";  # 

RE: Bug#198158: architecture i386 isn't i386 anymore

[Julian Mehnle]

Hi all,

I feel this whole discussion is somehow going into the wrong direction.  What 
does it matter now whether we drop support for i386 and i486 (and possibly 
more), or just i386?  Sooner or later we'll have the same problem (of changing 
the arch support being so difficult) again, if not with ix86 architectures, 
then with some other architecture.

If you ask me, the proper long-term solution would be to make the arch names 
sub-arch independent (i.e. "ix86" or "ia32" instead of "i386"), and then make 
the archs have versions (i.e. "ix86 3" = "i386", "ix86 5" = "i586") and -- if 
this can be viably done somehow -- features (i.e. "ix86 5 +mmx" = P MMX, "ix86 
6 +sse" = P III).  This would ease adding and dropping (and specifying 
required) arch support immensely in the future.  (A different syntax like 
"ix86-5-mmx" might be better, consider this a matter of discussion.)

I know it isn't simple to make these changes in Debian.  What do you think?

Julian.