Compromise for md5sum files [Was: Re: debsums for maintainer scripts]

[Goswin von Brederlow]

Hi,

how about the following compromise:

Instead of having a md5sums file inside the control.tar.gz the md5sums
file is added to the end deb archive as "md5sums". The file would
contain a sorted list of all files in data.tar.gz _and_ control.tar.gz
(moved into /var/lib/dpkg/info where they end up). (The md5sums file
would be generated by dpkg-deb and dh_md5sums would be made a dummy
saying its deprecated and removed from all sources over time.)

The debsums package (or dpkg directly) adds an option to keep the
md5sums file around or not. Which of the 2 should be the default
remains to be discussed (if debsums adds it it would be default to on,
if you don't want it purge debsums).

The md5sum of the md5sums file is added to the changes file (signed by
the maintainer) and to the Packages file by dinstall. It will also be
signed by debsigs.


Can everyone live with that?

MfG
Goswin

现代影院---把电影院搬回家.....处女洞房艳潭

[我要激情]

特大好消息:现代影院---把电影院搬回家

部分电影名:陷阱(韩语新片）

   处女洞房艳潭

   私家秘密处女
   
   爱抚乳房秘籍

   美丽女人_钢管舞   

   桌球裸女
   
   女人那话儿   

   水浒传之英雄好色
   
   色欲城市之绝色网吧
   
   唐朝旖丽男
   
   性书大亨
   
   齐天大性之大破盘丝洞
   
   偷窥无罪4淫人师表
   
   性爱二十四式
   
   欲火女郎
   
   晚会偷拍女孩更衣

   在线支付,安全快捷

   设有免费电影区,不花钱一样看电影 !!!

   每天都有新片,让您看不完

   加入"站长联盟",没有网站照样赚钱 !!! 

   还有更精彩的不便登出,请进来看看吧!!
 
http://www.njvod.com

本站出口1G带宽.提供在线观看服务(对网站带宽要求高,一般电影网无法提供),同时提供高速下载

初次见面,对本站不放心者请进本站论坛一看就明白.
http://www.bbs.njvod.com/dispbbs.asp?boardID=13&ID=2417
本站网速测试
http://www.njvod.com/speed/speedtest.asp

Re: Building Debian Completely From Source

[Michael K. Edwards]

On Friday 05 December 2003 08:03 pm, Goswin von Brederlow wrote:
> John Goerzen <[EMAIL PROTECTED]> writes:
[snip]
> > In other words, at no time would a .deb be downloaded.  All .debs would
> > be built locally and installed locally.

I did on-target-system builds of personal backports for quite a while, but 
have been much happier with the reproducibility of my work since I switched 
to using pbuilder and duploading to a personal repository running 
debarchiver.  I haven't fully automated the build-deps process, partly 
because I'm modifying sources one package at a time and partly because I am 
learning how to construct a reasonably secure environment for building and 
signing packages for public release.  At this stage I'm using my builds on 
test systems but suggesting that others fetch my diffs, look them over, and 
build their own packages if they want to test my work.

Depending on your paranoia level about package tampering, you may also find 
that you don't want to build your packages on general-purpose systems.  One 
approach is to harden one machine to serve as a local repository and firewall 
behind which to put your build machines.  Install the build systems from 
reliable media (official Debian CDs), pre-seed the repository with 
build-essential packages built however you like, and then pbuilder/sbuild 
your way to nirvana.

This way you will have a central location with a reasonable audit trail of how 
you built the packages you are running.  Your degree of trust in the package 
contents rests on your evaluation of security measures within your build 
farm, your confidence in the binaries used to bootstrap your process, and 
your ways of obtaining upstream source code and auditing diffs.  Sounds a lot 
like the Debian buildds, actually.  It's a big investment, and while it may 
be worth it to you, you might consider holding off until the process of 
building a Debian autobuilder is better documented (or, if you are able, 
contribute to that effort).

> There are several packages that have depends/build-depends
> loops. Without having a previous version you can't build them. That
> would make quite a bit of debian uninstalable for you.

These are presumably the packages with which you will need to pre-seed your 
repository.  Obviously the kernel and build-essential packages are in this 
category.  If the other build-depends loops in Debian have not at least been 
enumerated and evaluated to establish whether they are real or packaging 
bugs, the person who tackles this will be doing Debian a service.

> The method I use here (still experimental stage) is to have the
> original debian debs available for apt and a local repository of
> compiled sources. A script in /etc/apt/apt.conf.d monitors any deb
> that gets installed and adds original debian packages to the
> autobuilder queue. The autobuilder fetches the source and adds a 0.0.1
> to the version, a version higher than debians but lower than the next
> version, build the package and uploads it to the local repository. The
> next day an apt-get upgrade will upgrade to the locally build package.

Goswin, I'd be interested in reproducing your setup here, if you wouldn't mind 
sharing it.  Sounds like a good system for keeping a "guinea pig" machine 
current and catching FTBFS issues in the packages you actively track.

> The benefit is that you don't have to wait for days to install
> something. You don't end up in deadlocks with dependency cycles
> either.

The former is true if the original packages work on your system.  You might be 
running, say, a PaX kernel -- I understand that some binaries don't work 
until they are recompiled to be PaX-friendly.  Or you might be sticking to a 
"known good" glibc release, as I did with 2.2.5-final for quite a while, and 
so need to rebuild many binaries with versioned depends.  Or you might just 
not want ever to run a binary someone else compiled (barring, of course, your 
bootstrap build-essential packages).

The latter is not true if you are unwilling to install the debian binary 
package long enough to build your own.  Depends again on your reason for 
wanting to build your own copy of everything.  Personally, I have never yet 
had a business reason for this level of caution, but I can certainly imagine 
circumstances under which I would.

[snip]
> > We seem to already have the metadata necessary to do this, but as far as
> > I can tell, our existing tools don't support it.  For instance:
> >
> >  * apt-build has an option to build a package and all packages it
> >depends upon, but always downloads binary .debs of -dev packages.
> >(Or maybe I got this backwards; I'm not sitting at my apt-build
> >machine right now.)
> >
> >  * pbuilder and sbuild don't bother with actual installation,
> >so they don't resolve dependencies at all.  Also, they only download
> >.debs of build-deps.
> >
> > The nearest I have seen is fink, but I know little about it.
> >
> > Am I missing somethin

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Marc Haber]

On Sun, 7 Dec 2003 01:05:24 +1000, Anthony Towns
 wrote:
>On Sat, Dec 06, 2003 at 10:34:45AM +0100, Andreas Barth wrote:
>> > Seriously, I think you need to reconsider having the configuration in
>> > a separate package.
>> > What're you trying to achieve exactly?
>> Allowing for different configuration mechanismn. And I (as a user of
>> exim4) like that very much.
>
>There are plenty of things that could be described that way that don't
>involve having separate packages. There's a reason the word "exactly"
>appeared in the question above.

For example, the place I work has a package exim4-config-ilkserver
based on exim4-config-medium. That package installs without debconf
questions and contains a configuration that is suitable to our
non-main servers. It, for example, only delivers mail to local
accounts that are especially configured to receive mails.

When we need to change that configuration, the only thing necessary is
to build a new version of exim4-config-ilkserver and to put it on our
distribution server. cron-apt will automatically pull the new config
to the servers and optionally install it automatically. When a new
Debian version of exim4 is released, the binary packages can be
updated without affecting configuration. And if exim4's config file
format changes or our config starts using features only present beyond
exim 4.foo, we can use the Dependency mechanism to prevent
non-matching binary and config packages from being installed.

This is a great thing, and I like that idea very much.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

apt-file problem

[Arash Bijanzadeh]

tryingto search with apt-file gives me this error message:
Can't locate object method "host" via package "URI::_foreign" at /usr/bin/
apt-file line 225

How can I solve it?
-- 
Don't go around saying the world owes you a living.  The world owes you
nothing.  It was here first.
-- Mark Twain

Re: debsums for maintainer scripts

[Anthony DeRobertis]

On Fri, 2003-12-05 at 22:42, Goswin von Brederlow wrote:

> 
> The only reason attackers don't do it is because with rpm noone cares
> about the md5sums.

Would you care to provide some evidence as to why Debian having md5sums
on all pacakges would be any different for attackers than RedHat having
it? Please keep in mind:
  * Debian already has md5sums for many packages. 
  * RedHat already has md5sums on all packages
  * RedHat (probably) has a larger installed base than Debian
  * RedHat is more known than Debian to the general public

> Or the md5sum file was damaged.

The md5sum file is much smaller, and thus is much less likely to be hit
(by random chance)

> PS: even if debian had md5sum lists for each package they would be
> only current packages and not older version you would have installed.
> A signature inside the deb would last.

There is no technical reason we'd have to only have ones for the latest
version.


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

Re: Revival of the signed debs discussion

[Anthony DeRobertis]

On Fri, 2003-12-05 at 22:46, Goswin von Brederlow wrote:

> > No it isn't. For it to be non-repudiable, you'd have to demonstrate that
> > the key has not been compromised; that the developer knew what he was
> > signing (as opposed to a trojaned gpg telling him one thing while doing
> > another); etc. Proving those is quite impossible --- especially if he
> > doesn't want you to: He can always compromise his own key, on purpose.
> 
> If a package is compromised we can proof that the DD of the package
> either is malicious or incompetent. Two good reasons to exclude
> packages signed by him in the future. :)

Would you care to send that to <[EMAIL PROTECTED]>, perhaps?


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

fw我的亲身经历

[sdlzwsh]

fwÎÒµÄÇ×Éí¾­Àú
Fw: ¹ØÓÚÍø׬
 ÄúºÃ£¡
> ÎÒÀûÓÃÒµÓàʱ¼ä×öÁË´ó°ëÄêµÄÍø׬,¸÷ÖÖ¸÷ÑùÍø׬¶¼³¢ÊÔ¹ý£¬Ò²¼á³Ö¹ý£¬¿ÉÄÜÒ²ÏòÄãÃÇÍƼö
¹ý£¬×ۺϿ´À´£¬µÃ³öÒÔϽáÂÛ£º
> ¹úÍâµÄ¶¼ÊÇÆ­È˵Ķࣻ
> µã»÷¹ã¸æÔò¼«ÉÙÈËÄÜ´ïµ½×îµÍ¸¶½ð¶î£»
> ¸¶·Ñ·¢Õ¹Ï¼¶´úÀí50Ԫ̫¸ß£»
> Ö»ÓÐÒ»¸öÍø׬³É¹¦µÄ£¬ÄǾÍÊÇÒÚÁªÍøÂ磬ֻÐ踶³ö10Ôª£¬´ó¶àÊýÈ˶¼ÄܽÓÊÜ¡£
>ÎÒµÄÍøÖ·£ºhttp://www.fj35.com/so/?mid=wsh888  
>
> µ«Òª×ö³É¹¦,È´ÒªÓÐÒ»¶¨µÄºãÐÄ,Òª¼á³Ö²»Ð¸,²»ÊÇÿ¸öÈ˶¼»á¸øÄã¼Ä¿î,µ«Ö»ÒªÓи¶³ö,¾Í×Ü
»áÓÐÊÕ»ñ.
   ÈôÓв»Ã÷°×Ö®´¦£¬À´ÐÅ×Éѯ£¬ÓпÕÃæ̸¡£
>http://www.fj35.com/so/?mid=wsh888
>ÖÂ
>Àñ£¡
> 
>
>wsh888
>[EMAIL PROTECTED]
>2003-12-08

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Andreas Metzler]

Anthony Towns  wrote:
> On Fri, Dec 05, 2003 at 05:46:30PM +0100, Marc Haber wrote:
>> On Thu, 4 Dec 2003 13:43:39 +1000, Anthony Towns
>>  wrote:
>>> The one that gets installed later, Pre-Deps the one that gets installed
>>> earlier. exim4-daemon Pre-Depends: exim4-config; exim4-config Depends:
>>> exim4-base, probably.
>> Unfortunately, that doesn't work. 

> Err, of course it doesn't. What a stupid idea.

> Seriously, I think you need to reconsider having the configuration in
> a separate package.

> What're you trying to achieve exactly?

To keep dselect from installing -base and -config on upgrades from
woody if some other MTA is already installed.

Which has an obvious, ugly solution one comes up after stopping to think
too hard. ;-)

We only found it *after* wasting lots o time on IRC thinking through
the complicated workarounds like dependency circles with pre-depends,
and moving postinst to /usr/share/ to simulate dependencies.

Package: exim4-config
Conflicts: $list_of_packages_providing_MTA_in_sarge.

grep-available. EOT.
 cu andreas

-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: Bug#223114: marked as done ([INTL:de] german po-debconf translation)

[Christoph Berg]

Re: Debian Bug Tracking System in <[EMAIL PROTECTED]>
>* Added de debconf translation. Thanks to the german Skolelinux team
>  (closes: bug#2223114).

Well, I don't think we are *that* far yet...

Christoph
-- 
Christoph Berg <[EMAIL PROTECTED]>, http://www.df7cb.de/
Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944


signature.asc
Description: Digital signature

Re: debsums for maintainer scripts

[Goswin von Brederlow]

Anthony DeRobertis <[EMAIL PROTECTED]> writes:

> On Fri, 2003-12-05 at 22:42, Goswin von Brederlow wrote:
> 
> > 
> > The only reason attackers don't do it is because with rpm noone cares
> > about the md5sums.
> 
> Would you care to provide some evidence as to why Debian having md5sums
> on all pacakges would be any different for attackers than RedHat having
> it? Please keep in mind:

Its not the having part, its the using part.

>   * Debian already has md5sums for many packages. 
>   * RedHat already has md5sums on all packages
>   * RedHat (probably) has a larger installed base than Debian
>   * RedHat is more known than Debian to the general public
> 
> > Or the md5sum file was damaged.
> 
> The md5sum file is much smaller, and thus is much less likely to be hit
> (by random chance)
> 
> > PS: even if debian had md5sum lists for each package they would be
> > only current packages and not older version you would have installed.
> > A signature inside the deb would last.
> 
> There is no technical reason we'd have to only have ones for the latest
> version.

Space.

MfG
Goswin

Re: debsums for maintainer scripts

[Anthony DeRobertis]

On Sat, 2003-12-06 at 02:24, Manoj Srivastava wrote:

>   I am (probably) getting a Zaurus for christmas this year. I
>  would like to run Debian on it.  You think that the PDA has gobs of
>  disk space to throw around?

I think if you're worried about an extra few bytes per file from
md5sums, you're crazy, unless you've already saved space by doing the
following:
  * rm -Rf /usr/share/doc
  * recompile everything with -Os
  * replace glibc with, e.g., uclibc
  * build a minimal librarty set with mklibs.py
  * etc.

The space savings from the above would dwarf the space savings from
rm -f /var/lib/dpkg/info/*.md5sums.


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

Re: apell

[Henning Glawe]

On Sat, Dec 06, 2003 at 03:27:31PM -0800, Brian Nelson wrote:
> > if not: why was aspell _removed_ from stable and not replaced by a
> > backport of the version in unstable ?
> The upgrade to Aspell 0.50 is too big of a change for stable and would
> break a ton of stuff.
but just removing it doesn't break anything ?
googling around I read about some people being moderately angry because
of the removal.

-- 
c u
henning

Re: Intel f90 compiler for Debian.

[Petter Reinholdtsen]

[Lukas Geyer]
> The free software community would profit much more from making gcc's
> Fortran compiler compatible with the Fortran 95 standard.

Someone is already working on that.  Check
http://g95.sourceforge.net/>.  I'm sure more man-power would be
welcome. :)

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Tore Anderson]

* Tollef Fog Heen

 > It also makes it possible for packages such as clamav, spamassassin
 > and mailman to seamlessly drop in support in a fairly clean way.

  Which (possibly) makes the configuration break in a whole new way, if
 you decide to actually change the logic of stuff inside conf.d/.

  Suddenly you have a new spamassassin/clamav/whatever router inside
 the concatinated configuration that makes Exim route your email
 somewhere it shouldn't.

  As far as I know there is no way of telling the Exim packages "do not
 modify my customized configuration without asking me" as usually is the
 default elsewhere in Debian (and "configuration" here is of course the
 complete configuration as used by Exim, not the individual files in
 conf.d/), short of ignoring the Debian-provided default configuration
 entirely, by using /e/e/exim4.conf or setting conftype to none.

* Tore Anderson

 >   The Apache 2 packages does much of the same, sadly.

* Tollef Fog Heen

 > For the same reason, mostly.

  The good thing about the Apache 2 packages is that my resulting
 configuration won't be changed merely by downloading a new package
 (for it will put its snippet in the -available directories).  They
 don't split the configuration suff out from the -common/-base package,
 either.

 The -enabled directories/symlink farms and /etc/vhosts/* stuff is
 what's seems a tad strange and excessively Debian-specific to me;  I
 have preferred if the reccomended way for packages was to drop their
 example httpd.conf snippets in a single, standardized directory, and
 then the standard way of enabling these would be to simply Include 
 them from the main httpd.conf.  KISS and all that, y'know.

  But that's anyway just aesthetics to me.  Just ignore my ranting
 until I submit patches or constructive suggestions.  (I certainly
 would, if I were you.  :)

-- 
Tore Anderson

Re: recovery status update

[Roland Bauerschmidt]

Steve Langasek wrote:
> Hmm, I'm pretty sure the box is running stable, so this should be a
> non-issue (for now).

I see; thanks for the clarification. I just wanted to make sure...

Roland

Re: Intel f90 compiler for Debian.

[Henning Glawe]

On Sat, Dec 06, 2003 at 08:29:54PM -0500, Lukas Geyer wrote:
> Of course, if somebody (maybe you?) sends Intel some patches to make
> their compiler work on Debian systems, that can not be bad. As an
> aside, I don't quite understand why Fortran is still so popular in the
> numerical mathematics community... :)
My department uses self-made deps of ifc. while making them, we saw
already the rpm's were seriously broken (duplicate files in all of
them); intel's answer to this problem: just install them using
force-overwrite mode (!).

just write if someone wants the debs (I'll provide the diffs to 
intels distribution).

-- 
c u
henning

Re: Building Debian Completely From Source

[Antti-Juhani Kaijanaho]

On 20031206T145904-0600, John Goerzen wrote:
> Obviously gcc is the #1 example of this.  However, gcc packages should
> not need to depend on themselves; in our distribution, we tend to have
> many different versions of gcc available, and any of them should be able
> to build a newer gcc.

Nevertheless, *some* gcc version must build-depend either on itself or
on some gcc version that directly or indirectly build-depends on that
version.  Thus, multiple gcc versions do not fix the circular
build-depends problem.

> Nothing else in main comes to mind right now, though I'm sure there is
> something else...

Any self-hosting compiler.  We have several.  GHC is an example.

> But for everything but the C compiler, I think that the build probably
> should do the bootstrapping work itself wherever possible.

Bootstrapping on every build is not a good idea.  For most builds, it's
wasted work, since most builds will have a previous version available.
Furthermore, any bootstrapping build requires either a bootstrapping
compiler (and most languages do not have that in Debian) or distributing
a precompiled intermediate form (either C or assembly) that can be
further processed at build time to yield a bootstrapping compiler (which
IMHO is cheating - it's about as nice as distributing a bootstrapping
compiler executable in the source package).

-- 
Antti-Juhani Kaijanaho, Debian developer   http://www.iki.fi/gaia/


signature.asc
Description: Digital signature

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Nathanael Nerode]

Marc Wilson wrote:
>Just as a data point, you do realize that freedesktop.org is a wholly owned
>and operated subsidiary of RedHat, right?
Now this just isn't true.

>Oh, you don't think so?  Take a look at who their god-king is.  Take a look
>at where their mailing lists are hosted.  Karsten has detailed in another
>thread his interactions with that group.

Next you'll be saying that GNU binutils and GDB, and perhaps GCC, are
wholly owned and operated subsidiaries of Red Hat.  Look at who runs them...
look at where their mailing lists are hosted

The fact is that Red Hat is very generous about hosting free software
projects, and does not "own" or "operate" most of the projects it hosts.

-- 
Nathanael Nerode  
http://home.twcny.rr.com/nerode/neroden/fdl.html

Re: Bug#223114: marked as done ([INTL:de] german po-debconf translation)

[Aurelien Jarno]

On Sun, Dec 07, 2003 at 12:37:45PM +0100, Christoph Berg wrote:
> Re: Debian Bug Tracking System in <[EMAIL PROTECTED]>
> >* Added de debconf translation. Thanks to the german Skolelinux team
> >  (closes: bug#2223114).
> 
> Well, I don't think we are *that* far yet...

Hopefully we are not so far. It seem that I'll have either:
1) to look at kbdrate(1)
or
2) to sleep more during the nights :-)

Cheers,
Aurelien

-- 
  .''`.  Aurelien Jarno
 : :' :  Electrical Engineering Student | Debian GNU/Linux developer
 `. `'   [EMAIL PROTECTED]   | [EMAIL PROTECTED]
   `-www.aurel32.net| people.debian.org/~aurel32

how to handle multiple upstream changelogs

[Tommaso Moroni]

Hi!

The upstream sources of a package I maintain provide
changelogs in different subdirectories. What can I do 
to handle them?

The only idea I've come up with is to put the name of 
the corresponding subdirectory before each changelog.
Is there anyone who has resolved this problem in another
way?


Thanks
-- 
Tommaso Moroni
[EMAIL PROTECTED]

Re: how to handle multiple upstream changelogs

[Steve Kemp]

On Sun, Dec 07, 2003 at 03:18:54PM +0100, Tommaso Moroni wrote:

> The only idea I've come up with is to put the name of 
> the corresponding subdirectory before each changelog.
> Is there anyone who has resolved this problem in another
> way?

  I just took the "main" one and used that.

  Some packages I've made comprise of a library file and an
 executable which links to it, in that case I'd package them 
 seperately and that sidesteps the problem..

Steve
--
Will code for DVDs

Anfrage für ein Praktikum

[[EMAIL PROTECTED]]

Sehr geehrte(r) Frau, Herr,

Ich bin derzeit in einer Computerausbildung zum Projektleiter im Bereich 
Informatik in Frankreich und möchte ab März 2004 ein Praktikum absolvieren. Ich 
habe schon während 3 Jahre im EDV-Bereich gearbeitet. Ich spräche ein gut 
Englisch (3 Monate in Liverpool Universität).
Ich würde in meinem Praktikum gern mit dem UNIX-System und Datenbanken 
arbeiten. Ich habe gute Kenntnisse in Netzwerker und Internet. Aber ich kann 
auch in Programmierung arbeiten.

Das Projekt von dem ersten Jahre war die Kreation auf ein Software wer 
simuliert Industrieroboter. Eine Person programmiert und diese Software 
simuliert die Roboter. Das ist für kontrolliert ob das Programm ist gut bevor 
benutz sich in Realität.

Mein Projekt für diese letzte Jahre ist bauen einen Zentral System mit einen 
Linux Server. Alle die Computer werden mit dem Server vernetzen und ein 
„Operating System“ (Linux oder Windows) laden. Das Ziel auf diese System ist 
dass die Verwaltung und kontrollieren Software sind leichter. Ein andere Ziel 
ist für Geld sparen. Weniger Zeit für die Verwaltung, weniger Personen, nur ein 
OS Version und nur ein Software Version für alle Benutzer, nur ein Operation 
für ein Update. 
Diese System kann benutzen sowohl alte Computers als auch moderne Computers. 
Die Dauer auf Benutzung des Computers ist wichtiger.


Das Praktikum muss 6 Monate dauern.
Ich würde gerne eine größere Stadt kommen, um in ein Institut für deutsche 
Sprache gehen zu können, damit ich meine Sprachkenntnisse verbessern kann.
Ich bin sehr daran interessiert in Deutschland zu arbeiten. Ich glaube, dass 
Ihre Firma mit die Möglichkeit bieten kann, meine Kenntnisse im Bereich 
Informatik und der deutschen Sprache zu vertiefen.

Ich wurde mich sehr über einen Termin zu einem persönlichen Gespräch sehr 
freuen.


Mit vielen Dank für Ihre Aufmerksamkeit verbleibe ich mit freundlichen Grüssen,


Eric BRUNEAU




** L'ADSL A 20 EUR/MOIS** 
Avec Tiscali, l'ADSL est à 20 EUR/mois. Vous pourrez chercher longtemps avant 
de trouver moins cher ! 
Pour profiter de cette offre exceptionnelle, cliquez ici : 
http://register.tiscali.fr/adsl/
Offre soumise à conditions.


CVEricBRUNEAU_deustch.doc
Description: MS-Word document

Re: Anfrage für ein Praktikum

[Martin Pitt]

Hi Eric!

On 2003-12-07 15:38 +0100, [EMAIL PROTECTED] wrote:
> Ich bin derzeit in einer Computerausbildung zum Projektleiter im Bereich 
> Informatik in Frankreich und möchte ab März 2004 ein Praktikum absolvieren. 
> Ich habe schon während 3 Jahre im EDV-Bereich gearbeitet. Ich spräche ein gut 
> Englisch (3 Monate in Liverpool Universität).

[sic]

You seem to be completely off the track here: Debian GNU/Linux is a
free Linux distribution created and maintained by voluntary, non-paid
developers spread across the world. You cannot do things like a
hands-on training here because Debian is not a company. However, of
course you are invited to help :-)

In addition, this is an English mailing list. Please respect that.

Good luck anyway,

Martin

P.S. A hint for further applications: a computer science guy should
know how to handle his mail client. Endless lines with an odd
^M prefix might not make a good first impression...
-- 
Martin Pitt Debian GNU/Linux Developer
[EMAIL PROTECTED]  [EMAIL PROTECTED]
http://www.piware.de http://www.debian.org


signature.asc
Description: Digital signature

CV

[Sarah Al_Deghidy]

 

 

 

Sarah
El-Deghiedy

HR Department

FedEx Express -
Egypt

Licensee
Of Federal Express Corporation 

Phone : + 202 268 7999

Fax
: + 202 268 7555

Mob   
: + 20105148266

E-mail: Sarah [EMAIL PROTECTED]



 



 








Sarah.doc
Description: MS-Word document

CV

[Sarah Al_Deghidy]

 

 

 

Sarah
El-Deghiedy

HR Department

FedEx Express -
Egypt

Licensee
Of Federal Express Corporation 

Phone : + 202 268 7999

Fax
: + 202 268 7555

Mob   
: + 20105148266

E-mail: Sarah [EMAIL PROTECTED]



 



 








Sarah.doc
Description: MS-Word document

Re: Building Debian Completely From Source

[Scott James Remnant]

On Sat, 2003-12-06 at 20:59, John Goerzen wrote:

> On Sat, Dec 06, 2003 at 09:31:54PM +0200, Antti-Juhani Kaijanaho wrote:
> > For example, every self-hosting compiler build-depends on itself
> > (many of them can be bootstrapped, but I'm not sure we want to require
> > bootstrapping on every build - and some require manual bootstrapping
> > work).
> 
> Nothing else in main comes to mind right now, though I'm sure there is
> something else...
> 
make?  You'll need make installed to make make.  There are a huge number
of legitimate circular build dependencies, outlawing them won't help.

The way to deal with them is to go install the binary .deb you've
already got, then build the same package to get your "pristine" source
version.

Installing the gcc .deb to build gcc isn't any different from installing
any other cc, after all.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



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

Re: Anonymous upload queue

[Scott James Remnant]

On Sat, 2003-12-06 at 02:15, Brian May wrote:

> All large uploads (ie greater then several kb) hang when I try to
> upload them, so I can't test this...
> 
> Hmmm... Wonder if this is a local problem with my Internet connection or
> a problem with the remote system... Probably a local problem.
> 
Sounds like a duplex issue, or something similar?

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



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

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Anthony Towns]

On Sun, Dec 07, 2003 at 10:09:04AM +0100, Marc Haber wrote:
> For example, the place I work has a package exim4-config-ilkserver
> based on exim4-config-medium. That package installs without debconf
> questions and contains a configuration that is suitable to our
> non-main servers. It, for example, only delivers mail to local
> accounts that are especially configured to receive mails.

So, why can't this be done without an exim4-config package in Debian, with
something like the following arrangement:

exim4-daemon
provides/conflicts: mail-transport-agent
postinst:
checks /etc/exim4
if it doesn't exist, creates it, using debconf

exim4-config-ilkserver:
postinst:
rm -rf /etc/exim4
create /etc/exim4 according to desired config

# apt-get install exim4-config-ilkserver
# apt-get install exim4-daemon

> And if exim4's config file
> format changes or our config starts using features only present beyond
> exim 4.foo, we can use the Dependency mechanism to prevent
> non-matching binary and config packages from being installed.

This can be arranged by having:

exim4-daemon
provides: exim4-config-format-v1

exim4-config-ilkserver
depends: exim4-config-format-v1

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   Linux.conf.au 2004 -- Because we can.
   http://conf.linux.org.au/ -- Jan 12-17, 2004


pgp0chW34y6gx.pgp
Description: PGP signature

[PROPOSAL] definition of deb binary files

[Andreas Barth]

Hi,

I made a proposal of an updated deb format definition. I based that on
the manpage deb (part of dpkg-dev), and on reverse engineering of
dpkg-deb/build.c. I hope I've written the standard in a right and easy
to understandable way. I did (by purpose) not add anything about
signatures etc, but I just wanted to document what we have at current.
Discussion about additions should (IMHO) be kept seperate.

IMHO this definition should become part of the policy; I propose
either an new chapter 12, or an addition to chapter 3 Binary packages,
whatever seems more appropriate. This means that also some parts of
Appendix B could be removed at this occasion.

I'm also Ccing one bug of apt-utils, where I also got some of the
information from, and debian-devel. Please restrict the crossposting
on answers if usefull.


Cheers,
Andi


DESCRIPTION

The .deb format is the Debian binary package file format. It is understood
by dpkg 0.93.76 and later, and is generated by default by all versions
of dpkg since 1.2.0 and all i386/ELF versions since 1.1.1elf.

The format described here is used since Debian 0.93; details of the old
format are described in deb-old(5).


OVERALL FORMAT

The file is an ar archive in a certain ar version and with a magic number
of !. Due to the robustness principle, extracting tools should be
able to cope with as many of the different ar versions as possible; if they
don't, its at maximum a wishlist bug. On the other hand, tools providing
.deb-files MUST only provide strictly standard compatible files. Every
other behaviour is a serious bug!

The first member of the archive is name debian-binary and contains a series
of lines, separated by newlines. Currently only one line is present, the
format version number. The 2.0 format is current, and this format is
described in that document. Programs which read .deb-files should be
prepared for the minor number to be increased and new lines to be present,
and should ignore these if this is the case. If the major number has a
value a programm doesn't know, an incompatible change has happend, and
the program should abort with an error.


OVERALL AR FORMAT

The ar-format is (by purpose) one of the most ancient formats. This has the
reason that it should be possible to unpack .deb-files on as many different
computers as possible. Furthermore, it makes it also more easy for our code
to handle it.

Any ar files can be written as AR-FILE := HEADER [MEMBER]*.
The header is the string "!\n" (not null terminated).

Each member itself consists of the member head, and of the body, and, if
necessary, a padding '\n'. All information in the members head is printable
ascii, and each value is padded with spaces on the right side; at least one
space must be present, so the information must be shorter than the maximum
number of bytes available. The head is composed of the name (16 bytes), the
date in seconds since epoch (1970-1-1 0:00:00 UTC) in decimal notion (12
bytes), the uid and gid of the owner in decimal notion (each 6 bytes;
usually both 0), the file member mode in octal notion, begining with 1 (8
bytes; usually 100644), the size of the member body (the size is measure
without possible padding to the body; 10 bytes) and the two bytes "`\n".
After the member head, the member body follows unquoted; if the member body
has uneven lenght, it is padded with a single '\n'; so any members start on
an even byte boundry.

So, the initial member looks like:
debian-binary   1070194109  0 0 100644  4 `
2.0

Newer ar features (as longer file names, filesnames with spaces, ...) are
a violation of this standard; however, extracting tools should try to
support them as good as possible, but if they do not, that's just at
maximum a wishlist bug.


DEB 2 ARCHIVE MEMBERS

Archives with the major number 2 must have (after the initial member
debian-binary) in this exact order the members control.tar.gz and
data.tar.gz. After this, optional members can follow, but they must have a
'_' as the first character of their name.

control.tar.gz is a gzipped tar archive containing the package control
information, as a series of plain files, of which the file control is
mandatory and contains the core control information. Please see the Debian
Packaging Manual, section 2.2 for details of these files. The control
tarball may optionally contain an entry for `.', the current directory.

data.tar.gz contains the filesystem archive as a gzipped tar archive.


DEB 1 ARCHIVE MEMBERS

See the man-page deb-old(5) for a definition.
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Requirements on signatures on debs

[Andreas Barth]

* Andreas Barth ([EMAIL PROTECTED]) [031206 18:10]:
> I've tried to write down a list of requirements for the signature
> names (and what should be signed). I'll update the web version of this
> on http://debsigs.turmzimmer.net/policy.html

After some discussions, I updated my proposal (and also the website).

| Names of the signature files
| 
|There are quite different people and roles who handle a package during
|it's lifetime. These are (among others):
|  * Maintainer as part of the build process
|  * non-Maintainer as part of the build process (NMUs)
|  * sponsor
|  * buildd
|  * buildd-Admin (or is this aequivalent to the non-Maintainer?)
|  * dinstall for installing
| 
|These persons fall into three main categories:
|  * someone building a binary deb, e.g. a maintainer, a buildd, ...
|  * someone providing this deb as a part of the archive, e.g. dinstall
|  * someone approving a binary for a given situation, e.g. the
|security team for security.debian.org
| 
|Overall, _gpg is used as a general prefix. For the first category, the
|signature is named _gpgbuilder. For the second, a usefull name would
|be _gpgorigin (as "origin" is commonly used for such things, e.g. at
|apt pinning). For the third, this is a bit more complex, and so we
|leave it open. A commonly used name could be _gpgapproval, but
|everyone could use what he sees as usefull.
| 
|Sometimes (especially with the last one), there could be clashes. In
|the case of a clash, the new signature is created as
|[0-9A-Z], with the lowest free one. (That means, if
|_gpgapproval is used, the next one would be _gpgapproval0, and then
|_gpgapproval1, and so on.)
| 
|Some signatures are done by scripts, and some by human. This
|distinction can (and should) be made by the used key, not by anything
|else.
| 
| What the signature provides
| 
|Each signature signs:
|  * control and data information
|  * all previous signatures
|  * the time information that is embedded in the tar-files and inside
|the previous signatures
| 
|It should be possible to make signatures remote, without downloading
|the whole deb. For this, the signature is done over the md5sums (as
|provided by the md5sums-utility) of all ar members, in the order in
|which they are present in the archive. After doing the signature, the
|new archive member is appended to the deb file. No other way of
|altering the deb except appending a new signature is allowed;
|otherwise, the previous signatures could be broken.
| 
| Signature verification
| 
|If a signature is due to be verified, the md5sum of the previous
|archive members is made. The signature itself, and the following
|archive members are supressed for that. The signature is then verified
|on that md5sum. This has the bonus that signature verification could
|also be done by hand, for debugging or in special situations.

If there are any questions on this, I'm happy to answer them. If not,
I'll provide a debsigs-ng on my website that generates and verifies
conforming signatures.



Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Accounts on debian.org machines

[Bernd Eckenfels]

On Sun, Dec 07, 2003 at 09:27:53PM +0100, Tollef Fog Heen wrote:
> father's windows 2000 laptop when it's only connected to a NAT-ed
> internet connection.

How do you know it is not trojaned when u use it?

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: Accounts on debian.org machines

[Tollef Fog Heen]

* Matt Zimmerman 

| (Please follow up on a public list)

done, -devel has M-F-T set to.

| On Sun, Dec 07, 2003 at 06:26:48PM +0100, Tollef Fog Heen wrote:
| 
| > * Matt Zimmerman 
| >
| > | You would type a Debian password into a system that you do not trust
| > | with an ssh private key?
| > 
| > Yes, since I don't want to keep a key on them, since they are not
| > secure over time.  They are most likely secure when I'm sitting at the
| > console.  See above for an example: I don't trust that anything I put
| > permanently on the hard drive won't be compromised, however, I don't
| > think the box itself has any trojans or keysniffers installed.
| 
| This doesn't make sense to me; if the system is not trustworthy, then you
| should not trust it with any authentication data, whether passwords or ssh
| keys.

You are forgetting the temporal aspect here.  A machine may be viewed
as fairly safe when I have physical control of it.  That does not mean
that the machine is safe always, which is the case for, say my
father's windows 2000 laptop when it's only connected to a NAT-ed
internet connection.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Marc Haber]

On Mon, 8 Dec 2003 03:29:31 +1000, Anthony Towns
 wrote:
>So, why can't this be done without an exim4-config package in Debian, with
>something like the following arrangement:
>
>   exim4-daemon
>   provides/conflicts: mail-transport-agent
>   postinst:
>   checks /etc/exim4
>   if it doesn't exist, creates it, using debconf
>
>   exim4-config-ilkserver:
>   postinst:
>   rm -rf /etc/exim4
>   create /etc/exim4 according to desired config

That looks like a bad hack.

And it precludes the use of dpkg conffile handling for the config
snippets in /etc/exim4/conf.d

And it doesn't solve the problem at hand, with exim4-base being
installed on non-exim systems by dselect.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[Andreas Tille]

On Fri, 5 Dec 2003, cobaco wrote:

> > That's why I feeled obliged to add the remark that I greatly appreciate
> > the work of the SkoleLinux people and that they probably did more for
> > Debian than any CDD is out of any question.
>
> In the above sentence you seem to refer to Skolelinux as a CDD , yet from
> you're other replies it would seem you see them as a Debian-derivative.
> This seems inconsistent (am I misintepreting something here?)
I can't see why you think that I'm refering to SkoleLinux as CDD.  For
instance Joey Hess has done more for Debian than any CDD but Joey Hess
is definitely no CDD. ;-)

> -> you again seem to contradict yourself (this same problem for configuration
> applies for all CDD's at this point I think)
Well, I have to admit that I will now definitely stop spending my time
in correcting your missinterpretations of my mails and continue working
on Debian-Med.

Kind regards

 Andreas.

Re: debsums for maintainer scripts

[Anthony DeRobertis]

On Sun, 2003-12-07 at 06:45, Goswin von Brederlow wrote:
> Anthony DeRobertis <[EMAIL PROTECTED]> writes:
> 
> > On Fri, 2003-12-05 at 22:42, Goswin von Brederlow wrote:
> > 
> > > 
> > > The only reason attackers don't do it is because with rpm noone cares
> > > about the md5sums.
> > 
> > Would you care to provide some evidence as to why Debian having md5sums
> > on all pacakges would be any different for attackers than RedHat having
> > it? Please keep in mind:
> 
> Its not the having part, its the using part.

And Debian having a debsums program (an optional extra) would be more
using than RedHat having an rpm program (an essential part of the
system) would be more using, because...?

> > > PS: even if debian had md5sum lists for each package they would be
> > > only current packages and not older version you would have installed.
> > > A signature inside the deb would last.
> > 
> > There is no technical reason we'd have to only have ones for the latest
> > version.
> 
> Space.

Because the extra md5sums for the few packages updates since Woody was
released would take _so_ much mirror space. Possibly, even an entire
floppy disk's worth!


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

Re: Accounts on debian.org machines

[Tollef Fog Heen]

* Bernd Eckenfels 

| On Sun, Dec 07, 2003 at 09:27:53PM +0100, Tollef Fog Heen wrote:
| > father's windows 2000 laptop when it's only connected to a NAT-ed
| > internet connection.
| 
| How do you know it is not trojaned when u use it?

I don't.  Just like I don't know that my Debian laptop isn't trojaned.
Security isn't black and white, it's a lot of shades of gray. I try to
protect such things as ssh keys and gpg keys better than I protect
passwords, since they are changed a lot less often.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: debsums for maintainer scripts

[Goswin von Brederlow]

Anthony DeRobertis <[EMAIL PROTECTED]> writes:

> On Sun, 2003-12-07 at 06:45, Goswin von Brederlow wrote:
> > Anthony DeRobertis <[EMAIL PROTECTED]> writes:
> > 
> > > On Fri, 2003-12-05 at 22:42, Goswin von Brederlow wrote:
> > > 
> > > > 
> > > > The only reason attackers don't do it is because with rpm noone cares
> > > > about the md5sums.
> > > 
> > > Would you care to provide some evidence as to why Debian having md5sums
> > > on all pacakges would be any different for attackers than RedHat having
> > > it? Please keep in mind:
> > 
> > Its not the having part, its the using part.
> 
> And Debian having a debsums program (an optional extra) would be more
> using than RedHat having an rpm program (an essential part of the
> system) would be more using, because...?

Because we are talking about making verification checks enabled by
default. See also the signed debs thread that started this.

> > > > PS: even if debian had md5sum lists for each package they would be
> > > > only current packages and not older version you would have installed.
> > > > A signature inside the deb would last.
> > > 
> > > There is no technical reason we'd have to only have ones for the latest
> > > version.
> > 
> > Space.
> 
> Because the extra md5sums for the few packages updates since Woody was
> released would take _so_ much mirror space. Possibly, even an entire
> floppy disk's worth!

Having or not having is of the order of several 100MB. The shear
number of debs makes the impact.

MfG
Goswin

Re: [PROPOSAL] definition of deb binary files

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> Hi,
> 
> I made a proposal of an updated deb format definition. I based that on
> the manpage deb (part of dpkg-dev), and on reverse engineering of
> dpkg-deb/build.c. I hope I've written the standard in a right and easy
> to understandable way. I did (by purpose) not add anything about
> signatures etc, but I just wanted to document what we have at current.
> Discussion about additions should (IMHO) be kept seperate.
> 
> IMHO this definition should become part of the policy; I propose
> either an new chapter 12, or an addition to chapter 3 Binary packages,
> whatever seems more appropriate. This means that also some parts of
> Appendix B could be removed at this occasion.
> 
> I'm also Ccing one bug of apt-utils, where I also got some of the
> information from, and debian-devel. Please restrict the crossposting
> on answers if usefull.
> 
> 
> Cheers,
> Andi
> 
> 
> DESCRIPTION
> 
> The .deb format is the Debian binary package file format. It is understood
> by dpkg 0.93.76 and later, and is generated by default by all versions
> of dpkg since 1.2.0 and all i386/ELF versions since 1.1.1elf.
> 
> The format described here is used since Debian 0.93; details of the old
> format are described in deb-old(5).
> 
> 
> OVERALL FORMAT
> 
> The file is an ar archive in a certain ar version and with a magic number
^^^

Thats very vague. Explain what version and what that entails. That
also means explaining the limiting to short filenames and no spaces.
Is there more than bsd and sysv flavour in widespread use (if limited
to short names)?

> of !. Due to the robustness principle, extracting tools should be
> able to cope with as many of the different ar versions as possible; if they
> don't, its at maximum a wishlist bug. On the other hand, tools providing
> .deb-files MUST only provide strictly standard compatible files. Every
> other behaviour is a serious bug!
> 
> The first member of the archive is name debian-binary and contains a series
> of lines, separated by newlines. Currently only one line is present, the
> format version number. The 2.0 format is current, and this format is
> described in that document. Programs which read .deb-files should be
> prepared for the minor number to be increased and new lines to be present,
> and should ignore these if this is the case. If the major number has a
> value a programm doesn't know, an incompatible change has happend, and
> the program should abort with an error.

That sounds a lot like "make dep" but not exactly. Did you change the
odd bit here and there or rewrite that?

The rest of make deb should be included too, i.e. control.tar.gz and
data.tar.gz, naming rules for new members and the _ rule.


The manpage and this documentation should be worded the same.

> OVERALL AR FORMAT
> 
> The ar-format is (by purpose) one of the most ancient formats. This has the
> reason that it should be possible to unpack .deb-files on as many different
> computers as possible. Furthermore, it makes it also more easy for our code
> to handle it.
> 
> Any ar files can be written as AR-FILE := HEADER [MEMBER]*.
> The header is the string "!\n" (not null terminated).
> 
> Each member itself consists of the member head, and of the body, and, if
> necessary, a padding '\n'. All information in the members head is printable
> ascii, and each value is padded with spaces on the right side; at least one
> space must be present, so the information must be shorter than the maximum
> number of bytes available. The head is composed of the name (16 bytes), the
> date in seconds since epoch (1970-1-1 0:00:00 UTC) in decimal notion (12
> bytes), the uid and gid of the owner in decimal notion (each 6 bytes;
> usually both 0), the file member mode in octal notion, begining with 1 (8
> bytes; usually 100644), the size of the member body (the size is measure
> without possible padding to the body; 10 bytes) and the two bytes "`\n".
> After the member head, the member body follows unquoted; if the member body
> has uneven lenght, it is padded with a single '\n'; so any members start on
> an even byte boundry.
> 
> So, the initial member looks like:
> debian-binary   1070194109  0 0 100644  4 `
> 2.0

Can you add a hexdump -C of this? I think that might show it more
clearly. A complete ar file (byte 0 up to a few bytes of
control.tar.gz) would be better too to show the header as well.

> Newer ar features (as longer file names, filesnames with spaces, ...) are
> a violation of this standard; however, extracting tools should try to
> support them as good as possible, but if they do not, that's just at
> maximum a wishlist bug.

I think its better to follow the may/should/must rules of policy here:

Extracting tools should understand sysv and bsd ar files.
Extracting tools may support long filenames.
Tools providing debs must write policy conform debs.

The priority of a bug follows from that.

> D

Re: Accounts on debian.org machines

[Steve Langasek]

On Sun, Dec 07, 2003 at 09:27:53PM +0100, Tollef Fog Heen wrote:
> * Matt Zimmerman 

> | (Please follow up on a public list)

> done, -devel has M-F-T set to.

> | On Sun, Dec 07, 2003 at 06:26:48PM +0100, Tollef Fog Heen wrote:
> | 
> | > * Matt Zimmerman 
> | >
> | > | You would type a Debian password into a system that you do not trust
> | > | with an ssh private key?
> | > 
> | > Yes, since I don't want to keep a key on them, since they are not
> | > secure over time.  They are most likely secure when I'm sitting at the
> | > console.  See above for an example: I don't trust that anything I put
> | > permanently on the hard drive won't be compromised, however, I don't
> | > think the box itself has any trojans or keysniffers installed.
> | 
> | This doesn't make sense to me; if the system is not trustworthy, then you
> | should not trust it with any authentication data, whether passwords or ssh
> | keys.

> You are forgetting the temporal aspect here.  A machine may be viewed
> as fairly safe when I have physical control of it.  That does not mean
> that the machine is safe always, which is the case for, say my
> father's windows 2000 laptop when it's only connected to a NAT-ed
> internet connection.

But an ssh key on removable media is not vulnerable to keysniffing
alone, where a password is.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Bug#161593: [PROPOSAL] definition of deb binary files

[Wichert Akkerman]

Previously Andreas Barth wrote:
> IMHO this definition should become part of the policy; I propose
> either an new chapter 12, or an addition to chapter 3 Binary packages,

It should be part of the dpkg reference manual (partially online at
www.dpkg.org). Patches against the text as you can find in CVS are
welcome.

Wichert.

-- 
Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.

Re: Building Debian Completely From Source

[Goswin von Brederlow]

Scott James Remnant <[EMAIL PROTECTED]> writes:

> On Sat, 2003-12-06 at 20:59, John Goerzen wrote:
> 
> > On Sat, Dec 06, 2003 at 09:31:54PM +0200, Antti-Juhani Kaijanaho wrote:
> > > For example, every self-hosting compiler build-depends on itself
> > > (many of them can be bootstrapped, but I'm not sure we want to require
> > > bootstrapping on every build - and some require manual bootstrapping
> > > work).
> > 
> > Nothing else in main comes to mind right now, though I'm sure there is
> > something else...
> > 
> make?  You'll need make installed to make make.  There are a huge number
> of legitimate circular build dependencies, outlawing them won't help.
> 
> The way to deal with them is to go install the binary .deb you've
> already got, then build the same package to get your "pristine" source
> version.
> 
> Installing the gcc .deb to build gcc isn't any different from installing
> any other cc, after all.
> 
> Scott
> -- 
> Have you ever, ever felt like this?
> Had strange things happen?  Are you going round the twist?

All builds have build-essential installed already. Otherwise you would
never get out of circular build-depends. You don't realy want to start
from scratch.

But the remaining circles are evil.

MfG
Goswin

Re: Kernel 2.4.18 and GCC 3.3 (not a good mix)

[Rob Weir]

On Sat, Dec 06, 2003 at 05:05:02AM +0100, smurfd said
> Seems that gcc 3.3 and kernel 2.4.18 (with grsec patch) dont like
> eachother.

Yes, this is a well-known problem.  Use gcc 2.95.4 (which is still the
recommended compiler for 2.4, anyway) or upgrade to 2.4.23.  Also,
2.4.18 has at least two local root holes, one of which is not stopped by
grsecurity.

-- 
Rob Weir <[EMAIL PROTECTED]> | [EMAIL PROTECTED]  |  Do I look like I want a CC?
Words of the day:   enforcers enforcers tempest investigation Defcon Peking MDA


signature.asc
Description: Digital signature

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

[Patrick Ouellette]

On Thu, Dec 04, 2003 at 11:55:26AM -0800, Tom wrote:
> instance is the hacker sniffed the password, and then logged on to 
> Debian's servers later at his leisure from a different PC.  With a 

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.

The initial compromise would have been detected sooner, and project
machines protected *without* any additional hardware or money being
spent.


-- 

Patrick Ouellette
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Amateur Radio: KB8PYM 

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

[Russell Coker]

On Mon, 8 Dec 2003 13:16, Patrick Ouellette <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 04, 2003 at 11:55:26AM -0800, Tom wrote:
> > instance is the hacker sniffed the password, and then logged on to
> > Debian's servers later at his leisure from a different PC.  With a
>
> 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.  Therefore if the machine is cracked then the host key 
can be stolen and the machine impersonated.

Another problem is that host keys require SUID ssh client in the default 
configuration.  This is bad in that a ssh client can potentially be used to 
crack the machine, and it can potentially be used to steal the host key.

If we change ssh to be setgid not setuid for host based authentication then 
things will be marginally improved.  But another thing that should be done is 
to have ssh support for the host key used for host-based authentication not 
being the same as that used for incoming ssh connections.

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.

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

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Accounts on debian.org machines

[Matthew Garrett]

Steve Langasek wrote:

>But an ssh key on removable media is not vulnerable to keysniffing
>alone, where a password is.

If such behaviour becomes common, the keysniffers will simply copy
anything that looks like an SSH key that exists on an item of removable
media. There's no inherent increase in security from using a key on a
USB device other than the fact that attackers aren't thinking about that
yet.
-- 
Matthew Garrett | [EMAIL PROTECTED]

Authentication enhancements (was Re: Backport of the integer overflow in the brk system call)

[Patrick Ouellette]

On Mon, Dec 08, 2003 at 01:28:20PM +1100, Russell Coker wrote:
> 
> 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.

Your other very good points not withstanding, I was thinking along the
lines of the user's id substituting for the ip address in the
verification process.  User authentication would require a matched user
id & host id or a warning would be triggered.  

I didn't claim it was a perfect solution, I don't even claim it as a 
*good* solution.  It would be another layer of checks in the 
authentication process, with the benefit of not costing much in
terms of money.  

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

That is true for many of the suggested additions.  Once a trusted
machine is compromised, it's game over.  My suggestion would only send
up a flag if the attacker attempted to access project machines from
a host the user had not registered (assuming he did not know enough to
steal the host's key first).  If we could tie the host key to a unique
property of the physical host it would help.

In any event, I think there is merit in requiring a user / host
authentication pair if we can come up with a method of tying the host
key to the hardware.

I would be willing to work on such a task, if others also think it might
have merit.

-- 

Patrick Ouellette
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Amateur Radio: KB8PYM