Re: openssl-blacklist two keys per one pid
* Kees Cook: The rule is simple. When the ~/.rnd file doesn't exist I get one key and in other situation I get another (that listed in Ubuntu openssl-blacklist) key. Because of this problem openssl-blacklist has to be twice big than openssh-blacklist. I developed simple shell scripts to generate list of all key lengths we are interested in. They are attached. Yes, this was realized during the generation of the openssl-blacklist in Ubuntu. We're expecting to have the more complete lists published soon, for all 3 architectures. BTW, it appears that the same blacklist can be used for -3 and -F4 keys. (Just in case you haven't checked that already.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssl-blacklist two keys per one pid
Kees Cook wrote: The rule is simple. When the ~/.rnd file doesn't exist I get one key and in other situation I get another (that listed in Ubuntu openssl-blacklist) key. Because of this problem openssl-blacklist has to be twice big than openssh-blacklist. I developed simple shell scripts to generate list of all key lengths we are interested in. They are attached. Yes, this was realized during the generation of the openssl-blacklist in Ubuntu. We're expecting to have the more complete lists published soon, for all 3 architectures. I discovered that there is also 3rd key which you get if you pass empty file by -rand. Keys created in this way are still the same so it's another possible compromised key. I'm not sure if it worth spend time on counting this keys... I also published full list of compromited keys in lengths 1024 and 2048 for Intel 32bit and 64bit platforms on my website. There is more keys than in Ubuntu blacklist, but I'm missing others. I'm planning to publish 4096 bit keys list tomorrow. I'm not going to publish complete archives of private keys. Thanks! We can verify our lists against yours to make sure we're all on the same page. :) I deleted that one big file and published files split by architecture and key length: http://pocitace.tomasek.cz/debian-randomness/openssl-compromited-keys.rsa_1024_x86_32.txt http://pocitace.tomasek.cz/debian-randomness/openssl-compromited-keys.rsa_1024_x86_64.txt http://pocitace.tomasek.cz/debian-randomness/openssl-compromited-keys.rsa_2048_x86_32.txt http://pocitace.tomasek.cz/debian-randomness/openssl-compromited-keys.rsa_2048_x86_64.txt http://pocitace.tomasek.cz/debian-randomness/openssl-compromited-keys.rsa_4096_x86_32.txt http://pocitace.tomasek.cz/debian-randomness/openssl-compromited-keys.rsa_4096_x86_64.txt They are all complete now. 4096 took longer than I was expecting. What is your 3rd architecture? On Ubuntu pages I see only PC (Intel x86) desktop CD and 64-bit PC (AMD64) desktop CD? -- --- Jan Tomasek aka Semik http://www.tomasek.cz/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssl-blacklist two keys per one pid
On May 19, 2008, at 2:17 PM, Florian Weimer wrote: The rule is simple. When the ~/.rnd file doesn't exist I get one key and in other situation I get another (that listed in Ubuntu openssl-blacklist) key. Because of this problem openssl-blacklist has to be twice big than openssh-blacklist. I developed simple shell scripts to generate list of all key lengths we are interested in. They are attached. Yes, this was realized during the generation of the openssl- blacklist in Ubuntu. We're expecting to have the more complete lists published soon, for all 3 architectures. BTW, it appears that the same blacklist can be used for -3 and -F4 keys. (Just in case you haven't checked that already.) One way to do this a bit more careful may be by comparing the actual data itself. OpenSSL will output this with the modulus flag: openssl genrsa 1024 | openssl rsa -noout -modulus So then you (know) you are comparing the actual thing. Dw. $ rm ~/.rnd ; ./openssl genrsa -3 1024 2/dev/null | openssl rsa - noout -modulus $ rm ~/.rnd ; ./openssl genrsa -f4 1024 2/dev/null | openssl rsa - noout -modulus $ ./openssl genrsa -f4 1024 2/dev/null | openssl rsa -noout -modulus $ ./openssl genrsa -3 1024 2/dev/null | openssl rsa -noout -modulus Modulus=EE5750DD26F70AEAD7C40EA901B60231484D93F4E56A564D6E01BB55A64280DEB81D89F92ACB4876D1B4AFE4C5F8640AC45C2CD59168CA97B0F1565656B41B25D795F66E88FB8BDBC575CE8C12A9575B3B1CB5F3F4082B1848B1197B82786AF061CCDCDD419D23E342B1B77A510879B011E6F19D25754F5E30FAFC92AC79CA4D Modulus=EE5750DD26F70AEAD7C40EA901B60231484D93F4E56A564D6E01BB55A64280DEB81D89F92ACB4876D1B4AFE4C5F8640AC45C2CD59168CA97B0F1565656B41B25D795F66E88FB8BDBC575CE8C12A9575B3B1CB5F3F4082B1848B1197B82786AF061CCDCDD419D23E342B1B77A510879B011E6F19D25754F5E30FAFC92AC79CA4D Modulus=CBD028C5893EFBA1725BDFC4D5D9C3B2325E7569A27E0B5DF30785203D969FC1CA874C03FD151A2332BE54EE5DF6B3C2B55580AE68C6D998E0728B874922D48DE2AC43E4732AF67478F73BC66EDA8FDEC00E80C02E94D3457E4AFFBAF9CDAEF9B85BF504F774091D1D954FAD22584970CF0AC25D6A1CEA29A21E7BDF Modulus=CBD028C5893EFBA1725BDFC4D5D9C3B2325E7569A27E0B5DF30785203D969FC1CA874C03FD151A2332BE54EE5DF6B3C2B55580AE68C6D998E0728B874922D48DE2AC43E4732AF67478F73BC66EDA8FDEC00E80C02E94D3457E4AFFBAF9CDAEF9B85BF504F774091D1D954FAD22584970CF0AC25D6A1CEA29A21E7BDF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssl-blacklist two keys per one pid
* Dirk-Willem van Gulik: One way to do this a bit more careful may be by comparing the actual data itself. OpenSSL will output this with the modulus flag: openssl genrsa 1024 | openssl rsa -noout -modulus Yes, that's what dowkd is doing (albeit with a somewhat suboptimal algorithm; I should have used the most-significant bits, not the least-significant). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssl-blacklist two keys per one pid
On Mon, May 19, 2008 at 02:24:01PM +0200, Jan Tomasek wrote: What is your 3rd architecture? On Ubuntu pages I see only PC (Intel x86) desktop CD and 64-bit PC (AMD64) desktop CD? Sparc and PowerPC are big-endian with a 32-bit userspace. These exist in Debian currently, and existed in Ubuntu with the earlier releases. -- Kees Cook Ubuntu Security Team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssl-blacklist two keys per one pid
On May 19, 2008, at 2:54 PM, Florian Weimer wrote: * Dirk-Willem van Gulik: One way to do this a bit more careful may be by comparing the actual data itself. OpenSSL will output this with the modulus flag: openssl genrsa 1024 | openssl rsa -noout -modulus Yes, that's what dowkd is doing (albeit with a somewhat suboptimal algorithm; I should have used the most-significant bits, not the least-significant). Sure - the downside in a lot of those approaches is that they then proceed to generate an MD5 or SHA1 or just the modulus (in hex or binary), the String 'Modulus=...', with or without '\n' and/or then proceed to look at the whole md5/sha1 or just the last 20 chars or so. Working with the original and some indication as to what pid, platform, keylen endianness, and .rnd, is useful - as that way it is possible to understand, reconstruct, spotcheck or verify in-situ - rather than having to build trust without easy verify. So I'd publish/ship the original - and then derive everything else from it as/if needed (and given the speed of a 'grep' or that of an BDB) -- above/early optimizations may not be that crucial anyways. Thanks, Dw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssl-blacklist two keys per one pid
* Dirk-Willem van Gulik: Working with the original and some indication as to what pid, platform, keylen endianness, and .rnd, is useful - as that way it is possible to understand, reconstruct, spotcheck or verify in-situ - rather than having to build trust without easy verify. It's also trivial to recover the key material. For obvious reasons, I want to avoid that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
realpath in PS1 bash
Hi folks
I didn't receive any response on debian-user, hopefully this is an
appropriate place to ask.
I'm wondering if it would be a good idea to have PS1 set to
'${debian_chroot:+($debian_chroot)[EMAIL PROTECTED]:$(realpath $(pwd))\$ '
instead of the default
'${debian_chroot:+($debian_chroot)[EMAIL PROTECTED]:\w\$ '
and make it a suggestion in /etc/skel/.bashrc for those users who want
to see the actual current working directory.
From a security standpoint you could enter e.g.
/home/someoneelse/somedir/ and see [EMAIL PROTECTED]:/home/someoneelse/somedir/$
in the prompt, but really be in /etc/ if somedir is a (potentially
malicious) symlink to /etc created by a different user. It could get
quite disastrous if you decide to run something like rm -r * in such a
directory.
It won't be very helpful with more sophisticated symlink race
conditions, but it is better than nothing.
Perhaps I should post it to bash package wishlist, what do you think?
Peter Kuma
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator
Hi, you wrote: (...) A detector for known weak key material will be published at: http://security.debian.org/project/extra/dowkd/dowkd.pl.gz http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc (OpenPGP signature) (...) Thank you for providing a perl script to check for vulnerable keys! That was very helpfull especially for non debian systems where the fingerprints of vulnerable keys might hide in some authorized_keys files. Unfortunately, 4096 bit RSA keys have been used quite often and we are asked by sites how to check for these, too. Could you add the fingerprints of the keys offered on metasploit.com to dowkd.pl so at least those are checked? The 4096 bit RSA keys are on the site and the few I tested are indeed of the vulnerable set: http://metasploit.com/users/hdm/tools/debian-openssl/ Regards, Andreas -- Andreas Bunten (CSIRT), +49 40 808077-555 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstrasse 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski Automatische Warnmeldungenhttps://www.cert.dfn.de/autowarn smime.p7s Description: S/MIME Cryptographic Signature
Re: openssl-blacklist two keys per one pid
On May 19, 2008, at 3:15 PM, Florian Weimer wrote: * Dirk-Willem van Gulik: Working with the original and some indication as to what pid, platform, keylen endianness, and .rnd, is useful - as that way it is possible to understand, reconstruct, spotcheck or verify in-situ - rather than having to build trust without easy verify. It's also trivial to recover the key material. For obvious reasons, I want to avoid that. Given how trivial that is, and regardless, I'd rather see a focus on ensuring that the tools can be trusted, are absolutely complete and that such is relatively easy to verify. Thanks, Dw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator
On May 17, 2008, at 1:34 PM, Matteo Vescovi wrote: are there updates for this issue for old stable - sarge? It was said sarge is not affected, Bear in mind that you still want blacklist support for the various tools, not just for the known_hosts and authorized_keys; but also for people who move their identify files around, generate the web/mail server's their x509 cert (request) on a laptop/off-line prior to moving it onto the server and so on*. Dw. *: I found about a 1 to 3901 ratio between affected and non-affected keys out of about 50k ssh-keys and 21k x509's (using the not yet complete lists!) in an environment which is virtually only Windows, MacOSX and FreeBSD. I think it is reasonable to assume that this is fairly common - hence you want these blacklist tools on a wider range of platforms/OS-es. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dowkd.pl false positives
On May 17, 2008, at 2:23 PM, Florian Weimer wrote: Someone has added a warning to the wiki page http://wiki.debian.org/SSLkeys that dowdkd.pl produces many false positives. Even if there are bugs in the script, this is *very* unlikely. Could someone please provide such an alleged false positive? Perhaps confusion over false negatives - as the current ring does not include all endian/cpu flavours - it is possible (currently) for it to return no compromised keys - while there are in fact some. As the tool does not yet check for all keys. Dw. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh-vulnkey and authorized_keys
Alex Samad wrote:
On Thu, May 15, 2008 at 07:43:13PM -0400, Chris Adams wrote:
On May 15, 2008, at 6:25 PM, Alex Samad wrote:
is there away to check x509 certs with these tools ?
Yes - the wiki has one (http://wiki.debian.org/SSLkeys) but you might
prefer the openssl-blacklist package which Ubuntu prepared:
https://launchpad.net/ubuntu/+source/openssl-blacklist/
It runs out of the box on Debian and if you edit debian/control to
change the openssl dependency from the Ubuntu version
(0.9.8g-4ubuntu3.1) to the Debian version (0.9.8c-4etch3) you can dpkg-
buildpackage it and deploy it to multiple systems. I used it like this
to flush out Apache keys:
sudo find /etc/ -xdev -type f -name \*.key -exec openssl-vulnkey {} \;
I have done this and check some .key files, but they show up as not
blacklisted, when I know they have been created in the last 12 months. I
thought I read some where the keys are different depending on weather it
was generated on a 32b or 64b system.
You might want to update the blacklist with the 64b generated keys
Chris
From what I understand ssh-vulnkey only check to see if a key is listed in the
blacklist (already compromised). Is there any way to empirically test whether
a key is vulnerable or not?
--Jim
Re: ssh-vulnkey and authorized_keys
* James Miller: From what I understand ssh-vulnkey only check to see if a key is listed in the blacklist (already compromised). Is there any way to empirically test whether a key is vulnerable or not? All vulnerable keys should be contained in the blacklist. In other words, the blacklist should be complete. There is no known way to test for a weak key, except for looking it up in a pre-generated blacklist. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssl-blacklist two keys per one pid
Dirk-Willem van Gulik wrote: On May 19, 2008, at 3:15 PM, Florian Weimer wrote: * Dirk-Willem van Gulik: Working with the original and some indication as to what pid, platform, keylen endianness, and .rnd, is useful - as that way it is possible to understand, reconstruct, spotcheck or verify in-situ - rather than having to build trust without easy verify. It's also trivial to recover the key material. For obvious reasons, I want to avoid that. Given how trivial that is, and regardless, I'd rather see a focus on ensuring that the tools can be trusted, are absolutely complete and that such is relatively easy to verify. This is good argument. When I was trying to secure my systems from weak SSH keys. I decided to use ssh-vulnkey and build blacklists by myself from work of H D Moore. I do not trust dowkd.pl script because it lacks info where keys were taken. It also reported 0 weak keys even if there were keys of rare length, I presume unknown to dowkd.pl. I agree that there is need to have tool which everyone can easy verify. When attacker want to attack a host running SSH he have to try number keys and he even do not known if that host have some weak key installed. With X509 certificates it's different. They are public, everyone can take my certificate. With X509 certificate in hands he can simply lookup database, pick private key and sign as if it was me. Scary. It's even worse because many software is lacking support for CRL. Including Thunderbird I'm using. I realized that I did stupid mistake when I published PID used to create key. :( I removed old databases. And published new which contains openssl-blacklist compatible hash and Modulus. I hope this might help other people to create their blacklists but it doesn't reduce time needed for finding right key. That time is short anyway. To build my lists I need 3days of 2x Quad Core Intel processors. Such computation power can have everyone. If Debian or Ubuntu Security teams are interested I can share private keys with them, but publishing them on web really isn't good idea. Best regards -- --- Jan Tomasek aka Semik http://www.tomasek.cz/ signature.asc Description: OpenPGP digital signature
Re: openssl-blacklist two keys per one pid
* Jan Tomasek: This is good argument. When I was trying to secure my systems from weak SSH keys. I decided to use ssh-vulnkey and build blacklists by myself from work of H D Moore. I do not trust dowkd.pl script because it lacks info where keys were taken. We did not want to publish this information in order to give system administrators at least a tiny bit of lead in patching and reconfiguring their systems. It also reported 0 weak keys even if there were keys of rare length, I presume unknown to dowkd.pl. I agree that there is need to have tool which everyone can easy verify. Yes, this was a serious issue in the user interface, but it has been fixed in the meantime. If Debian or Ubuntu Security teams are interested I can share private keys with them, but publishing them on web really isn't good idea. For me, dowkd-compatible fingerprints are enough in most cases. Only if there is a discrepancy (perhaps due to a random bit flip), we might need the keys for comparison. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: [SECURITY] [DSA 1576-1] New openssh packages fix predictable randomness
Hola: Por si les interesa, hay una alerta de seguridad en debian. Saludos Leonardo From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 14 May 2008 11:24:56 +0200 Subject: [SECURITY] [DSA 1576-1] New openssh packages fix predictable randomness -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-1576-1 [EMAIL PROTECTED] http://www.debian.org/security/ Florian Weimer May 14, 2008 http://www.debian.org/security/faq - Package: openssh Vulnerability : predictable random number generator Problem type : remote Debian-specific: yes CVE Id(s) : CVE-2008-0166 The recently announced vulnerability in Debian's openssl package (DSA-1571-1, CVE-2008-0166) indirectly affects OpenSSH. As a result, all user and host keys generated using broken versions of the openssl package must be considered untrustworthy, even after the openssl update has been applied. 1. Install the security updates This update contains a dependency on the openssl update and will automatically install a corrected version of the libss0.9.8 package, and a new package openssh-blacklist. Once the update is applied, weak user keys will be automatically rejected where possible (though they cannot be detected in all cases). If you are using such keys for user authentication, they will immediately stop working and will need to be replaced (see step 3). OpenSSH host keys can be automatically regenerated when the OpenSSH security update is applied. The update will prompt for confirmation before taking this step. 2. Update OpenSSH known_hosts files The regeneration of host keys will cause a warning to be displayed when connecting to the system using SSH until the host key is updated in the known_hosts file. The warning will look like this: @@@ @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. In this case, the host key has simply been changed, and you should update the relevant known_hosts file as indicated in the error message. It is recommended that you use a trustworthy channel to exchange the server key. It is found in the file /etc/ssh/ssh_host_rsa_key.pub on the server; it's fingerprint can be printed using the command: ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub In addition to user-specific known_hosts files, there may be a system-wide known hosts file /etc/ssh/known_hosts. This is file is used both by the ssh client and by sshd for the hosts.equiv functionality. This file needs to be updated as well. 3. Check all OpenSSH user keys The safest course of action is to regenerate all OpenSSH user keys, except where it can be established to a high degree of certainty that the key was generated on an unaffected system. Check whether your key is affected by running the ssh-vulnkey tool, included in the security update. By default, ssh-vulnkey will check the standard location for user keys (~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity), your authorized_keys file (~/.ssh/authorized_keys and ~/.ssh/authorized_keys2), and the system's host keys (/etc/ssh/ssh_host_dsa_key and /etc/ssh/ssh_host_rsa_key). To check all your own keys, assuming they are in the standard locations (~/.ssh/id_rsa, ~/.ssh/id_dsa, or ~/.ssh/identity): ssh-vulnkey To check all keys on your system: sudo ssh-vulnkey -a To check a key in a non-standard location: ssh-vulnkey /path/to/key If ssh-vulnkey says Unknown (no blacklist information), then it has no information about whether that key is affected. In this case, you can examine the modification time (mtime) of the file using ls -l. Keys generated before September 2006 are not affected. Keep in mind that, although unlikely, backup procedures may have changed the file date back in time (or the system clock may have been incorrectly set). If in doubt, generate a new key and remove the old one from any servers. 4. Regenerate any affected user keys OpenSSH keys used for user authentication must be manually regenerated, including those which may have since been transferred to a different system after being generated. New keys can be generated using ssh-keygen, e.g.: $
RE: [SECURITY] [DSA 1576-2] New openssh packages fix predictable randomness
Hola: Por si les interesa, hay una alerta de seguridad en debian. Saludos Leonardo From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Fri, 16 May 2008 18:14:27 +0200 Subject: [SECURITY] [DSA 1576-2] New openssh packages fix predictable randomness -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-1576-2 [EMAIL PROTECTED] http://www.debian.org/security/ Noah Meyerhans May 16, 2008 http://www.debian.org/security/faq - Package: openssh Vulnerability : predictable random number generator Problem type : remote Debian-specific: yes CVE Id(s) : CVE-2008-0166 Matt Zimmerman discovered that entries in ~/.ssh/authorized_keys with options (such as no-port-forwarding or forced commands) were ignored by the new ssh-vulnkey tool introduced in openssh 1:4.3p2-9etch1 (see DSA 1576-1). This could cause some compromised keys not to be listed in ssh-vulnkey's output. This update also adds more information to ssh-vulnkey's manual page. For the stable distribution (etch), this problem has been fixed in version 1:4.3p2-9etch2 We recommend that you upgrade your openssh (1:4.3p2-9etch2) package. Upgrade instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 4.0 alias etch - --- Stable updates are available for alpha, amd64, arm, hppa, i386, ia64, mipsel, powerpc, s390 and sparc. Source archives: http://security.debian.org/pool/updates/main/o/openssh/openssh_4.3p2-9etch2.dsc Size/MD5 checksum: 1010 7bcad5f65ff1722db7c431d3a25e8578 http://security.debian.org/pool/updates/main/o/openssh/openssh_4.3p2.orig.tar.gz Size/MD5 checksum: 920186 239fc801443acaffd4c1f111948ee69c http://security.debian.org/pool/updates/main/o/openssh/openssh_4.3p2-9etch2.diff.gz Size/MD5 checksum: 276621 27984546be5ba87687ae6e7e5df36578 Architecture independent packages: http://security.debian.org/pool/updates/main/o/openssh/ssh-krb5_4.3p2-9etch2_all.deb Size/MD5 checksum:92022 1cd59a62eb401f21421f13a6caf3d509 http://security.debian.org/pool/updates/main/o/openssh/ssh_4.3p2-9etch2_all.deb Size/MD5 checksum: 1052 b096153814cc8949820d9958f8b81a00 alpha architecture (DEC Alpha) http://security.debian.org/pool/updates/main/o/openssh/ssh-askpass-gnome_4.3p2-9etch2_alpha.deb Size/MD5 checksum: 100498 2fa04ed9e0ee9625f28964938cc19b64 http://security.debian.org/pool/updates/main/o/openssh/openssh-client_4.3p2-9etch2_alpha.deb Size/MD5 checksum: 782726 0c48b38fc56cdaedb3d4a1eab9ecd25d http://security.debian.org/pool/updates/main/o/openssh/openssh-server-udeb_4.3p2-9etch2_alpha.udeb Size/MD5 checksum: 213728 ff4b07cb720fb26210c3a49213737168 http://security.debian.org/pool/updates/main/o/openssh/openssh-server_4.3p2-9etch2_alpha.deb Size/MD5 checksum: 266510 113583573c885f7baa40b9a78933c6aa http://security.debian.org/pool/updates/main/o/openssh/openssh-client-udeb_4.3p2-9etch2_alpha.udeb Size/MD5 checksum: 198498 6dd01cb3b4fe5cf3726142f429281187 amd64 architecture (AMD x86_64 (AMD64)) http://security.debian.org/pool/updates/main/o/openssh/ssh-askpass-gnome_4.3p2-9etch2_amd64.deb Size/MD5 checksum: 100106 b4dc14aee0a9c94d96e3b392a2dd61e8 http://security.debian.org/pool/updates/main/o/openssh/openssh-client_4.3p2-9etch2_amd64.deb Size/MD5 checksum: 711910 dc68b26b2810e7f47e3fa419c262bc07 http://security.debian.org/pool/updates/main/o/openssh/openssh-server_4.3p2-9etch2_amd64.deb Size/MD5 checksum: 245522 b02dc226eb5aae330b08429a17f0eef6 http://security.debian.org/pool/updates/main/o/openssh/openssh-server-udeb_4.3p2-9etch2_amd64.udeb Size/MD5 checksum: 183854 fa96f8d05d380a6053672de0a6bd30c1 http://security.debian.org/pool/updates/main/o/openssh/openssh-client-udeb_4.3p2-9etch2_amd64.udeb Size/MD5 checksum: 171334 b2eafdc135649523828db8416f22617d arm architecture (ARM) http://security.debian.org/pool/updates/main/o/openssh/openssh-server_4.3p2-9etch2_arm.deb Size/MD5 checksum: 218980 6065fa1195e74549c7dd66fbe2b41718 http://security.debian.org/pool/updates/main/o/openssh/ssh-askpass-gnome_4.3p2-9etch2_arm.deb Size/MD5 checksum:99668
Re: realpath in PS1 bash
In article [EMAIL PROTECTED] you wrote:
I'm wondering if it would be a good idea to have PS1 set to
'${debian_chroot:+($debian_chroot)[EMAIL PROTECTED]:$(realpath $(pwd))\$ '
Personally I dont like having the shell spawn a executable. Since this will
slow down administration on heavyly loaded systems. Maybe \pwd -P as a
shell builtin acts a bit nicer. However I am not sure if it results in the
same path in all cases. And it is still traversing lots of inodes.
Gruss
Bernd
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: realpath in PS1 bash
* Bernd Eckenfels: And it is still traversing lots of inodes. It's pretty much likely that those paths are in the dcache anyway, so there's no need to fall back on inodes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
