Re: Changing the "Reply-To:" for debian-security-announce

[Florent Rougon]

Andrew Vaughan  wrote:

> I'm wondering why the body of the email doesn't include instructions on how
> to unsubscribe?  Most modern email clients

[...]

> Just adding "To unsubscribe email:debian-security-requ...@lists.debian.org
> with the subject unsubscribe" at the bottom of every email might halve
> the noise.

Could you please *carefully* read what you replied to (judging from the
subject of your email)?

The problem is *not* people being unable to unsubscribe from
debian-security. Most of them probably are not even subscribed to it! If
you look at all these "please unsubscribe me" emails, you'll see very
clearly from the subjects and quoted texts that those people are
replying to mails they received from debian-security-announce@l.d.o,
*not* debian-security@l.d.o. Therefore, putting more garbage into
footers for debian-security@l.d.o mails is not going to help.

People not subscribed to debian-security@l.d.o are quite unlikely to
read your "improved" mail footers; moreover, this is not what they need
since their problem is that they are subscribed to
debian-security-announce@l.d.o.

Please read carefully. Otherwise, you are only adding noise, I'm afraid.

-- 
Florent

Re: Changing the "Reply-To:" for debian-security-announce

[Florent Rougon]

Alexander Wirt  wrote:

> Because people expect that they can answer a DSA.

Okay, but what's the point? If someone has something valuable to say in
response to a DSA:

  1) he can find the debian-security list;

  2) if he replies to the -announce list and gets a bounce because the
 Reply-To address is invalid, he should eventually get to point 1
 himself, otherwise I fear he can't write anything really
 interesting... And to mitigate the "problem", The Reply-To address
 can give a hint, like this:

  dont-reply-to-this-list-subscribe-to-debian-security-instead@invalid

Because this kind of stupid traffic considerably reduces the list's
signal to noise ratio[1], therefore making sacrifices just so that
dumb/careless/overly lazy/egoistic users can reply to DSAs *without any
effort* is counter-productive IMHO—all the more since many of them are
likely not to be able to even read the answers, being only be subscribed
to debian-security!

(sorry if I sound elitist here, just being pragmatic...)

Regards


  [1] Which is self-amplified, because smart/knowledgeable people with
  hard time constraints are then likely to unsubscribe or read the
  list too fast if they are used to mostly see noise there.

-- 
Florent

Re: [SECURITY] [DSA 3500-1] openssl security update

[Florent Rougon]

Carsten Aulbert  wrote:

> Would it make sense to add that to the DSA 3500-1 page, like for
> DSA-3481[1]?

Probably (if not already the case---didn't check). But frankly, *every*
library with a security update falls in this case AFAICT, so if you're
going to do that, do it for *all* of them, I'd say.

-- 
Florent

Re: [SECURITY] [DSA 3501-1] perl security update

[Florent Rougon]

Noah Meyerhans  wrote:

> He replied to a post to debian-security-annou...@lists.debian.org yet
> everybody who replied to him how to unsubscribe from
> debian-security@lists.debian.org. Amazing how he's still on the list,
> isn't it?

Yup. Wouldn't it be possible to set the Reply-To, Mail-Followup-To and
whatnot for debian-security-announce to some address in ending with
@invalid or @example.com? 'cause replying to an announce list without
even checking the destination address is ill-minded behavior in the
first place if you ask me...

-- 
Florent

Re: About GPG-signing the public RSA keys of Debian machines

[Florent Rougon]

Hi,

I appreciate your help (Joerg, David and Kurt), but there is still a
problem to solve before I can trust my connection to db.debian.org via
HTTPS.

Kurt Roeckx [EMAIL PROTECTED] wrote:

 So Joerg just replaced them with the new ones:
 http://www.spi-inc.org/secretary/spi-ca.crt
 http://www.spi-inc.org/secretary/spi-ca.crt.fingerprint.txt

OK, I downloaded these, verified the first using the second, and
imported the first one in both firefox and galeon.

Then, when I point galeon or firefox to https://db.debian.org/, I get
the usual message saying the certificate is not trusted. The reason is
that the certificate I imported
(http://www.spi-inc.org/secretary/spi-ca.crt) is *not* the same as the
one advertised by db.debian.org: the former expires in 2016 (!) and has
the following SHA1 fingerprint:

  D4:CB:C2:DE:8A:CE:1C:4E:4C:96:17:AA:DC:BD:9E:BA:FB:66:2C:94

while the latter expires in 2007 and has this SHA1 fingerprint:

  AA:50:E3:2F:6E:AE:40:91:CB:F8:...

(cannot copy/paste from the firefox dialog box! :-/)

 They're both part of the ca-certificates package in testing and
 unstable:
 new: /etc/ssl/certs/SPI_CA_2006-cacert.pem
 old: /etc/ssl/certs/spi-ca.pem

It appears that http://www.spi-inc.org/secretary/spi-ca.crt and
/etc/ssl/certs/SPI_CA_2006-cacert.pem are exactly the same files.
Why do they have different extensions? This is very confusing.

   % md5sum /etc/ssl/certs/spi-ca.pem
   33922a1660820e44812e7ddc392878cb  /etc/ssl/certs/spi-ca.pem

 As pointed out by others, you can get to it using openssl.

I had thought about that, but grepping for fingerprint in openssl(1ssl)
doesn't bring anything. :-(

 But you can also try and import the key in your browser, and they say
 examine/view certificate, at which point it should show you the
 MD5 sum and SHA1 sum too.

Right, that's the easiest way. Works in galeon and firefox.

 The fingerprint of an ssh key is also something you don't check by
 running md5sum on a id_rsa.pub file, you use ssh-keygen -l for it.

True, but grepping for fingerprint in ssh(1) gives the answer as the
first hit.

 But it's alot handier that the whole public key is also available
 on the website.

I'm not sure I understand you here. The public RSA keys *are* available.
The problem is trusting them. I proposed GPG-signing them, but using SSL
is another way.

Thanks.

PS: sorry for the delays when answering; I have a very busy week...

-- 
Florent


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

Re: About GPG-signing the public RSA keys of Debian machines

[Florent Rougon]

Kurt Roeckx [EMAIL PROTECTED] wrote:

 The certificate for db.debian.org is still signed by the old key.

Mmmm.

  They're both part of the ca-certificates package in testing and
  unstable:
  new: /etc/ssl/certs/SPI_CA_2006-cacert.pem
  old: /etc/ssl/certs/spi-ca.pem
 
 It appears that http://www.spi-inc.org/secretary/spi-ca.crt and
 /etc/ssl/certs/SPI_CA_2006-cacert.pem are exactly the same files.
 Why do they have different extensions? This is very confusing.

 So you need /etc/ssl/certs/spi-ca.pem, and not

whose fingerprints are GPG-signed here:

  http://www.spi-inc.org/secretary/spi-ca-old-fingerprint.txt

(by Wichert Akkerman). Good.

 /etc/ssl/certs/SPI_CA_2006-cacert.pem.  Importing that works for me, but
 I suggest you import both now.

OK, this works fine.

 pem is the file format, and most files in /etc/ssl/certs have that
 extention, certificates will be in that file format.  The .crt
 extention is ussually used to say it's a certicate, and not the
 private key or something.

Hmmm, I see. Still a mess, though...

 See man x509(1ssl).  openssl has alot of subcommands, each having it's
 own manpage.  If you don't know what you're looking for, it might be
 hard to find.

Quite true. Once, I started reading openssl(1ssl), but found that very
difficult to understand if you aren't already knowledgeable about SSL,
certificates and such.

Thanks for the pointers!

-- 
Florent


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

Re: About GPG-signing the public RSA keys of Debian machines

[Florent Rougon]

Hi,

Joerg Jaspert [EMAIL PROTECTED] wrote:

   1. There is also:
  * Entry created: /00/00 00:00:00 UTC
  * Entry modified: /00/00 00:00:00 UTC 

 Those fields could be removed and not shown, that would fix this. Its
 just that in the past we had those filled in, now we dont (show them anymore).

Okay...

   2. Even worse, the page has:
Last Modified: Tue, Feb 1 19:13:06 UTC 2005
  which is *way before* the compromize. Ugh.

 Yes, but that only means the html code for the layout, not the page
 itself. The page is generated dynamically.

This explains well why the last modified date predates the compromize,
but IMHO, the fact that said date only applies to the page template is
not at all obvious when reading the page.

   2. I have to trust the integrity of db.debian.org.

 Signing the keys you would have to trust whoever signed it. Same thing.

I don't think both processes give the same trust level; David gave good
arguments why, so I won't repeat them here.

Regards,

-- 
Florent


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

Re: About GPG-signing the public RSA keys of Debian machines

[Florent Rougon]

Hi,

David Clymer [EMAIL PROTECTED] wrote:

 With a signature, he just has to trust that signer f00's key has not
 been compromised, thus the published host key info is trustworthy and a
 MITM is not happening.

To be honest, I believe the MITM attack problem could be mitigated by
the certificate when accessing db.debian.org via HTTPS instead of HTTP.

But trusting the certificate is still a problem for me. Even with
ca-certificates installed, galeon says the certificate cannot be
trusted; I subsequently imported the certs from /etc/ssl/certs into
galeon, which brought the question of whether I trusted that this came
from Autoridade Certificadora Raiz Brasileira, at which point I
answered no.

In contrast to this, the principle of the GPG web of trust is crystal
clear.

-- 
Florent


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

Re: About GPG-signing the public RSA keys of Debian machines

[Florent Rougon]

[ I think debian-admin have read enough about my request by now, so if
  you reply about verifying certificates and such, please consider
  dropping the CC. Thanks. ]

Kurt Roeckx [EMAIL PROTECTED] wrote:

 See:
 http://lists.debian.org/debian-project/2006/07/msg00056.html
 Which has the key in it, and is signed by James Troup.

Good, thanks. IMHO, this mail should have been sent to dda, as happened
with the compromize of 2003. This time, there was a mail to dda, ending
with We'll post more info as soon as we reasonably can, and nothing
followed... for those who read dda and not -project. I did search
through dda before starting this thread, and couldn't find what I was
looking for (i.e., the new RSA key in a GPG-signed mail).

 Most Debian hosts should have an /etc/ssh/ssh_known_hosts with all host
 keys in.  I suggest you read:
 http://db.debian.org/doc-hosts.html

I had read that before starting the thread of course, but that doesn't
point to GPG-signed RSA keys.

 Anyway, if you don't trust db.debian.org, how did you log in the
 first time to any Debian machine?

The first time, yes, I had to trust the advertised key (I checked there
was nothing obviously weird with the DNS data, but that's about it).
However, this is not a reason to be careless when ssh warns you about
the server using a new key.

And you're actually reinforcing my point: had the RSA keys been
available in a GPG-signed message on db.debian.org, I would not have had
to blindly accept the key the first time.

 I assume you've used https and that you verified the certificate?
 And saw that it was issued by SPI?  And then you looked up SPI's
 certificate?  And you found that there is a text file with the SHA1 and
 MD5 sum signed by Wichert Akkerman?

Unfortunately, I'm not that competent with certificates. I already wrote
I gave up when asked whether I trusted some entity in Brazil I had never
heard about.

 For those that don't know those files:
 http://www.spi-inc.org/secretary/spi-ca.crt
 http://www.spi-inc.org/secretary/spi-ca-fingerprint.txt

I didn't know these URLs, and I wouldn't bet they are well-known among
DDs... Anyway, I can verify the GPG sig of spi-ca-fingerprint.txt, but
then I don't know what the MD5 and SHA1 sums in it correspond to.

The file contains:

  MD5 Fingerprint=ED:85:3A:FD:32:43:13:73:91:4D:94:06:C4:10:EB:E5

but unfortunately:

  % md5sum /etc/ssl/certs/spi-ca.pem
  33922a1660820e44812e7ddc392878cb  /etc/ssl/certs/spi-ca.pem

And reading /etc/ssl/certs/spi-ca.pem is not very enlightening:

-BEGIN CERTIFICATE-
MIIEFTCCA36gAwIBAgIBADANBgkqhkiG9w0BAQQFADCBvjELMAkGA1UEBhMCVVMx
EDAOBgNVBAgTB0luZGlhbmExFTATBgNVBAcTDEluZGlhbmFwb2xpczEoMCYGA1UE

[...]

iexO/AlorB49KnkFS7TjCAoLOZhcg5FaNiKnlstMI5krQmau1Qnb/vGSNsE/UGms
1ts+QYPUs0KmGEAFUri2XzLy+aQo9Kw74VBvqnxvaaMeY5yMcKNOieY=
-END CERTIFICATE-

It would be nice to have the whole procedure for verifying the
authenticity of the certificates documented somewhere...

Thanks for your reply.

-- 
Florent


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

About GPG-signing the public RSA keys of Debian machines

[Florent Rougon]

Hi,

I wanted to login on gluck today and stumbled on that:

  @@@
  @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
  @@@
  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  It is also possible that the RSA host key has just been changed.
  The fingerprint for the RSA key sent by the remote host is
  ca:59:44:a0:0d:9e:5c:45:39:2b:a0:75:9a:d4:45:fe.
  Please contact your system administrator.

  [...]

OK. This is probably caused by the reinstallation mentioned on
http://lists.debian.org/debian-devel-announce/2006/07/msg3.html.

But replacing an ssh key is not something to take lightly, IMHO.
Right, I can compare the advertised fingerprint with that published on:

  https://db.debian.org/machines.cgi?host=gluck

Both are identical. But:

  1. There is also:

 * Entry created: /00/00 00:00:00 UTC
 * Entry modified: /00/00 00:00:00 UTC 

 which is not reassuring.

  2. Even worse, the page has:

   Last Modified: Tue, Feb 1 19:13:06 UTC 2005

 which is *way before* the compromize. Ugh.

  2. I have to trust the integrity of db.debian.org.

I think it would be much better if someone from debian-admin would be so
kind to GPG-sign the public RSA keys of Debian hosts. This way, I'd only
have to trust that James Troup and Martin Schulze[1] take good care of
their GPG keys.

That would make me more comfortable replacing my current entry for gluck
in ~/.ssh/known_hosts.

Thoughts? Does that already exist and I missed it? (Google didn't help)

Thanks.


  [1] Or any other person in charge of the machines, the point being,
  *few* of them, and people I really have to trust when using Debian
  anyway.

-- 
Florent


pgpfYcS9Dg2x1.pgp
Description: PGP signature

Re: su - and su - what is the real difference?

[Florent Rougon]

Goswin von Brederlow [EMAIL PROTECTED] wrote:

 if (isatty (0)  (cp = ttyname (0))) {

 For this to succeed the stdin must be a terminal. But nothing stops
 you from using a pseudo terminal (pty).

You're right, that works. Thanks.

My conclusion is that whether using su or su - from a non-privileged
user account doesn't really matter from a security POV, because you're
stuffed as soon as an attacker having access to this account makes you
run his own su wrapper (which is quite doable) to record the root
password.

-- 
Florent


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

Re: su - and su - what is the real difference?

[Florent Rougon]

Florent Rougon [EMAIL PROTECTED] wrote:

 Is it possible for a malicious su wrapper to:

   1. record root's password (of course, yes);

   2. *and then* feed this password to the real su.

 I suspect the real su empties the stdin buffer (or something like
 that) to avoid such attacks, but would be glad to hear a confirmation
 from people who know better.

OK, answering my own question. su has the following code:

if (isatty (0)  (cp = ttyname (0))) {

[...]

} else {
if (!amroot) {
fprintf (stderr,
 _(%s: must be run from a terminal\n), Prog);
exit (1);
}
tty = ???;
}

with the result that the attached program fails this way:

  % ./autosu.py
  su: must be run from a terminal
  Child exit status: 1
  %

#! /usr/bin/env python

# autosu.py --- Try to su to root, with the password given by the program, not
#   the user.
# Copyright (c) 2006 Florent Rougon
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 dated June, 1991.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program; see the file COPYING. If not, write to the
# Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
# Boston, MA  02110-1301 USA.

import sys, os, time

class Bug(Exception):
pass


def main():
(rfd, wfd) = os.pipe()
child_pid = os.fork()

if child_pid == 0:
# We are in the child process. We MUST NOT raise any exception.
try:
os.dup2(rfd, 0)
os.execvp(su, [su, root, -c, id])
except:
os._exit(127)

# Should not happen unless there is a bug in Python
os._exit(126)

# We are in the father process.
time.sleep(2)

f = os.fdopen(wfd, wb)
f.write(v3ry s3kr3t p455w0rd\n)
f.flush()
f.close()

exit_info = os.waitpid(child_pid, 0)[1]
if os.WIFEXITED(exit_info):
exit_code = os.WEXITSTATUS(exit_info)
elif os.WIFSIGNALED(exit_info):
sys.exit(Child terminated by signal %u % os.WTERMSIG(exit_info))
else:
raise Bug()

print Child exit status: %u % exit_code

sys.exit(0)

if __name__ == __main__: main()

-- 
Florent

Re: su - and su - what is the real difference?

[Florent Rougon]

Michael Marsh [EMAIL PROTECTED] wrote:

 What this means is that if you just run su, you'll be left with the
 environment of the user from whose account you entered root's.  In
 particular, $PATH, $LD_PRELOAD, and $LD_LIBRARY_PATH won't be unset.
 If the user is malicious, he can get you to run different programs
 than you thought you were running.  That includes dynamically linking
 in (for example) a trojaned version of libc.  It's precisely because
 your euid becomes 0 that this is a problem, since the malicious user
 can set up a root-privileged back door.

I'm wondering whether using su - is really safer.

We are considering the case where the user account used to run the
command is compromised (or the user owning this account is malicious,
which is more or less the same). He can easily trick you into believing
you're running /bin/su, whereas you're running some program of his
(using a shell function, or for more robustness exec()ing a modified
shell upon login where /bin/su actually calls a malicious program from
the user account). But this trick is really successful only if the fake
su program can eventually call the real one to get you root access
(otherwise, you'll quickly notice there is something wrong).

Is it possible for a malicious su wrapper to:

  1. record root's password (of course, yes);

  2. *and then* feed this password to the real su.

I suspect the real su empties the stdin buffer (or something like
that) to avoid such attacks, but would be glad to hear a confirmation
from people who know better.

Thanks.

-- 
Florent


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

Re: su - and su - what is the real difference?

[Florent Rougon]

LeVA [EMAIL PROTECTED] wrote:

 And can you tell me why the $USER and the $LOGNAME variables gets 
 resetted by su, no matter if I've invoked it with or without the '-' 
 option?

Which suite are you testing this on?

Here, on sarge, using su with the - sets USER to root but doesn't
modify LOGNAME.

-- 
Florent


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

Re: su - and su - what is the real difference?

[Florent Rougon]

Oops!

Florent Rougon [EMAIL PROTECTED] wrote:

 Here, on sarge, using su with the - sets USER to root but doesn't
   
  without

 modify LOGNAME.

Sorry for the confusion.

(of course, with su -, LOGNAME is set to 'root')

-- 
Florent


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

Re: .desktop arbitrary program execution

[Florent Rougon]

Florian Weimer [EMAIL PROTECTED] wrote:

 mutt and Gnus are, in typical configurations.  Most distributions
 kindly add all these helpful mailcap entries.

Could you point out a mailcap entry that causes the file to be
*executed*?

Because running gqview $file.jpg is very different from running
$file.jpg and you would do it (with the viewer of your choice) just
the same but by hand, with less helpful MUAs.

Just curious.

-- 
Florent


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

Re: Security FAQ

[Florent Rougon]

[ I'm not subscribed to debian-www ]

Johan Haggi [EMAIL PROTECTED] wrote:

 Maybe you want to add this at security faq:

 === Question ===
 To use sarge's security updates I write this line in sources.list:
 deb http://security.debian.org/ sarge/updates main contrib non-free
 Why they don't say that it exist??

The 'testing' distribution is not supported by the Debian security team.

 === Answer ===
 Because it is obsolete!!! At 26 Jan 2004
 http://security.debian.org/dists/sarge/updates/main/binary-i386/Packages
 was of 29-May-2003 !!!

You are writing this as if you expected it to be up-to-date. But you
shouldn't even expect it to exist at all.

 security.debian.org sarge/updates exists only because [???]

Because then it will be ready for sarge's release, so that it isn't
delayed by the need to setup the security infrastructure like happened
with woody? Or simply to allow the security team to update packages
there if they want to (possibly before sarge's release, to catch up with
security issues that were fixed in woody)? Or to make it clear that the
main thing that is needed to have security updates for 'testing' is a
bunch of skilled and trusted volonteers?

Of course, these are only guesses, as I am in no way a member of the
security team.

-- 
Florent


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

Re: Security FAQ

[Florent Rougon]

[ I'm not subscribed to debian-www ]

Johan Haggi [EMAIL PROTECTED] wrote:

 Maybe you want to add this at security faq:

 === Question ===
 To use sarge's security updates I write this line in sources.list:
 deb http://security.debian.org/ sarge/updates main contrib non-free
 Why they don't say that it exist??

The 'testing' distribution is not supported by the Debian security team.

 === Answer ===
 Because it is obsolete!!! At 26 Jan 2004
 http://security.debian.org/dists/sarge/updates/main/binary-i386/Packages
 was of 29-May-2003 !!!

You are writing this as if you expected it to be up-to-date. But you
shouldn't even expect it to exist at all.

 security.debian.org sarge/updates exists only because [???]

Because then it will be ready for sarge's release, so that it isn't
delayed by the need to setup the security infrastructure like happened
with woody? Or simply to allow the security team to update packages
there if they want to (possibly before sarge's release, to catch up with
security issues that were fixed in woody)? Or to make it clear that the
main thing that is needed to have security updates for 'testing' is a
bunch of skilled and trusted volonteers?

Of course, these are only guesses, as I am in no way a member of the
security team.

-- 
Florent

Re: apt-get upgrade and kernel images

[Florent Rougon]

Andris Kalnozols [EMAIL PROTECTED] wrote:

 lpans1# dpkg -l | grep kernel-image
 ii  kernel-image-2 2.4.23-1   Linux kernel image for version 2.4.23 on PPr
 ii  kernel-image-2 2.4.24-2   Linux kernel image for version 2.4.24 on PPr
  ^^

Note that the package name is truncated with dpkg -l
(cf. dpkg-query...).

 lpans1# apt-get upgrade
 Reading Package Lists... Done
 Building Dependency Tree... Done
 The following packages will be upgraded:
   console-common console-data console-tools ddd gettext gettext-base
   gettext-el kernel-image-2.4.24-1-686-smp libconsole libgphoto2-2
  ^

[...]

 Why is apt-get now bringing in kernel-image packages and needlessly so
 since I already have the indicated version installed?

What you underlined is the package _name_, not version. If you want to
know the versions, you can use dpkg -l kernel-image-2.4.24-1-686-smp
or dpkg -s kernel-image-2.4.24-1-686-smp, for the installed version,
apt-cache show kernel-image-2.4.24-1-686-smp for the available
version, or do all this in dselect.

What apt wants to do here is an upgrade of the
kernel-image-2.4.24-1-686-smp package (presumably a security update,
given the recent events).

What will not happen automatically is an upgrade from a 2.4.24 kernel to
a 2.4.25 kernel for instance. These are provided by two different
packages.

-- 
Florent


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

Re: apt-get upgrade and kernel images

[Florent Rougon]

Andris Kalnozols [EMAIL PROTECTED] wrote:

 lpans1# dpkg -l | grep kernel-image
 ii  kernel-image-2 2.4.23-1   Linux kernel image for version 2.4.23 on PPr
 ii  kernel-image-2 2.4.24-2   Linux kernel image for version 2.4.24 on PPr
  ^^

Note that the package name is truncated with dpkg -l
(cf. dpkg-query...).

 lpans1# apt-get upgrade
 Reading Package Lists... Done
 Building Dependency Tree... Done
 The following packages will be upgraded:
   console-common console-data console-tools ddd gettext gettext-base
   gettext-el kernel-image-2.4.24-1-686-smp libconsole libgphoto2-2
  ^

[...]

 Why is apt-get now bringing in kernel-image packages and needlessly so
 since I already have the indicated version installed?

What you underlined is the package _name_, not version. If you want to
know the versions, you can use dpkg -l kernel-image-2.4.24-1-686-smp
or dpkg -s kernel-image-2.4.24-1-686-smp, for the installed version,
apt-cache show kernel-image-2.4.24-1-686-smp for the available
version, or do all this in dselect.

What apt wants to do here is an upgrade of the
kernel-image-2.4.24-1-686-smp package (presumably a security update,
given the recent events).

What will not happen automatically is an upgrade from a 2.4.24 kernel to
a 2.4.25 kernel for instance. These are provided by two different
packages.

-- 
Florent

Re: Mail processing tool

[Florent Rougon]

Jonas J Linde [EMAIL PROTECTED] wrote:

 Procmail is a big tool, I need something different: small, reliable, 
 secure. 

 Big? The gzipped source tar ball is 227kB. If you want something that
 processes mail in a fully customizable way I'm pretty sure you won't find
 anything much smaller than that.

Well, the procmail source code is written in a very... bizarre style. In
my book, it doesn't qualify as reliable.

And please, don't think you can start flaming right away because you
have been using procmail for the past ten years or so and never had the
slightest impression of it losing a mail. That is not the point. The
point is that its source code is very unpleasant to me, so *I* wouldn't
rely on it for anything serious. That has nothing to do with your
experience of its use.

-- 
Florent


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

Re: Mail processing tool

[Florent Rougon]

Jonas J Linde [EMAIL PROTECTED] wrote:

 Procmail is a big tool, I need something different: small, reliable, 
 secure. 

 Big? The gzipped source tar ball is 227kB. If you want something that
 processes mail in a fully customizable way I'm pretty sure you won't find
 anything much smaller than that.

Well, the procmail source code is written in a very... bizarre style. In
my book, it doesn't qualify as reliable.

And please, don't think you can start flaming right away because you
have been using procmail for the past ten years or so and never had the
slightest impression of it losing a mail. That is not the point. The
point is that its source code is very unpleasant to me, so *I* wouldn't
rely on it for anything serious. That has nothing to do with your
experience of its use.

-- 
Florent

Re: secure FTP clients [was: recommendations for FTP server]

[Florent Rougon]

Nick Boyce [EMAIL PROTECTED] wrote:

 Don't forget FileZilla
   http://filezilla.sourceforge.net/
 
 GUI Win32 client that does FTP, FTP over SSL, and SFTP.  Apparently
 has some integration with PuTTY,though I can't currently figure out
 how to get FileZilla to use my PuTTY keystore.

The way I see it is:
  - I load (with Pageant) a key to log as $USER on $HOST
  - I fire filezilla and make an SFTP connection as $USER to $HOST
  - when prompted for the password, I just type garbage
  - the login is successful, meaning FileZilla used the key loaded by
Pageant to perform the authentication.

 Seems nice and stable to me.

Agreed. A nice free-as-in-speech software for Windows.

-- 
Florent


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

Re: secure FTP clients [was: recommendations for FTP server]

[Florent Rougon]

Nick Boyce [EMAIL PROTECTED] wrote:

 Don't forget FileZilla
   http://filezilla.sourceforge.net/
 
 GUI Win32 client that does FTP, FTP over SSL, and SFTP.  Apparently
 has some integration with PuTTY,though I can't currently figure out
 how to get FileZilla to use my PuTTY keystore.

The way I see it is:
  - I load (with Pageant) a key to log as $USER on $HOST
  - I fire filezilla and make an SFTP connection as $USER to $HOST
  - when prompted for the password, I just type garbage
  - the login is successful, meaning FileZilla used the key loaded by
Pageant to perform the authentication.

 Seems nice and stable to me.

Agreed. A nice free-as-in-speech software for Windows.

-- 
Florent

Re: AW: export problems on security updates?

[Florent Rougon]

Marcel Weber [EMAIL PROTECTED] wrote:

 I think he meant France with the limitation of 56 bit encription.

It doesn't exist any more. It used to be 128 bits for some time (I think
it's still 128 bits for undeclared secret-key crypto-systems, but
IANAL), and since the 15th of July 2002, the key size is *unlimited*
AIUI for GnuPG and OpenSSL (because they have been declared to the
appropriate authority---the DCSSI---which delivered authorizations that
expire in July 2007). See:

  http://france.fsfeurope.org/dcssi/dcssi.fr.html

for more info.

-- 
Florent


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

Re: AW: export problems on security updates?

[Florent Rougon]

Marcel Weber [EMAIL PROTECTED] wrote:

 I think he meant France with the limitation of 56 bit encription.

It doesn't exist any more. It used to be 128 bits for some time (I think
it's still 128 bits for undeclared secret-key crypto-systems, but
IANAL), and since the 15th of July 2002, the key size is *unlimited*
AIUI for GnuPG and OpenSSL (because they have been declared to the
appropriate authority---the DCSSI---which delivered authorizations that
expire in July 2007). See:

  http://france.fsfeurope.org/dcssi/dcssi.fr.html

for more info.

-- 
Florent

Re: Bug#149714: libfam0 Does not depend on fam

[Florent Rougon]

Hi,

Anthony DeRobertis [EMAIL PROTECTED] wrote:

 There is a package for doing that (setting up those pseudo-packages) but I
 don't remember the name. Sorry :-(

I think you mean equivs.

-- 
Florent

Re: NEWS RELEASE

[Florent Rougon]

Christoph Moench-Tegeder [EMAIL PROTECTED] wrote:

 It's your fault if you don't filter on X-Spam-Status.

FYI (sorry for the long line), it was:

X-Spam-Status: No, hits=4.3 required=4.7 
tests=SUBJ_ALL_CAPS,CLICK_BELOW,SUBJ_REMOVE,MAILTO_WITH_SUBJ,MAILTO_WITH_SUBJ_REMOVE,SUPERLONG_LINE,FREQ_SPAM_PHRASE
 version=2.01

-- 
Florent


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

ssh and password authentication

[Florent Rougon]

Hi,

I have read several times, including on this list, that password
authentication with ssh does not send the password in clear text (it is
sent in the encrypted tunnel). This is confirmed by the ssh(1) man page:

 If other authentication methods fail, ssh prompts the user for a
 password. The password is sent to the remote host for checking;
 however, since all communications are encrypted, the password
 cannot be seen by someone listening on the network.

But the default sshd_config in the openssh-3.0.2p1 package has a comment
indicating the contrary:

,
| # To disable tunneled clear text passwords, change to no here!
| PasswordAuthentication yes
`

and according to that comment, the default setting would be insecure...
I don't believe it, but the comment seems to be a real bug (and an
upstream one, since it also appears in the .orig.tar.gz).

Any thoughts? Thanks.

-- 
Florent


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