monkeysphere issueshttps://0xacab.org/monkeysphere/monkeysphere/-/issues2020-07-14T09:59:33Zhttps://0xacab.org/monkeysphere/monkeysphere/-/issues/11239Duplicate trust core created on fork failure2020-07-14T09:59:33ZAndrew GallagherDuplicate trust core created on fork failureTwice now the following sequence of events has happened:
1. Our ubuntu 18.04 server experiences pthread starvation leading to lockup:
```
runtime/cgo: pthread_create failed: Resource temporarily unavailable
SIGABRT: abort
```
2. We re...Twice now the following sequence of events has happened:
1. Our ubuntu 18.04 server experiences pthread starvation leading to lockup:
```
runtime/cgo: pthread_create failed: Resource temporarily unavailable
SIGABRT: abort
```
2. We restart the server
3. cron.hourly/monkeysphere starts failing:
```
/etc/cron.hourly/monkeysphere:
monkeysphere-authentication gave up after 6 tries
```
The proximate cause is that monkeysphere has created a duplicate trust core. ma/setup assumes that only one exists, and fails with error 2 on finding an unexpected newline in the output of `$(core_fingerprint)`. The quick fix is to purge and reinstall monkeysphere.
I suspect this is due to missing error handling, which fails to catch a (transient) fork failure and treats it as a nonexistent trust core; it then attempts to create a new one automatically and sometimes is lucky enough to succeed...https://0xacab.org/monkeysphere/monkeysphere/-/issues/11238gpg2 instead of gpg2020-03-10T09:50:30ZStacy Harpergpg2 instead of gpgHello all !
I'm currently trying to package monkeysphere and other tools on VoidLinux where we got gpg and gpg2 as different packages.
[voidlinux packaging](https://github.com/void-linux/void-packages/pull/20001)
I got this problem:
`...Hello all !
I'm currently trying to package monkeysphere and other tools on VoidLinux where we got gpg and gpg2 as different packages.
[voidlinux packaging](https://github.com/void-linux/void-packages/pull/20001)
I got this problem:
```
$ monkeysphere update-known_hosts
Monkeysphere needs GnuPG >= 2.1.11
```
monkeysphere seems to try to use gpg and I'd like to configure it to use gpg2.
How should I do this?
I saw there is a GPG env variable used in the monkeysphere script but it do not works as expected.
Thanks by advance for your replies!https://0xacab.org/monkeysphere/monkeysphere/-/issues/11237elliptic curve (ed25519) support2018-11-15T21:59:57Zanarcatelliptic curve (ed25519) supportWhen Monkeysign encounters a ed25519 authentication key, it fails to translate it in a matching ed25519 SSH key for the user.
Example:
```
$ gpg --export --export-option export-minimal --no-armor 260E858CA9D2505D9E2C471569361A59A066B65...When Monkeysign encounters a ed25519 authentication key, it fails to translate it in a matching ed25519 SSH key for the user.
Example:
```
$ gpg --export --export-option export-minimal --no-armor 260E858CA9D2505D9E2C471569361A59A066B658 | openpgp2ssh "micah@riseup.net"
We only support RSA keys (this key used algorithm 22).
We only support RSA keys (this key used algorithm 22).
We only support RSA keys (this key used algorithm 18).
No matching key found.
```
Algo 18 is, I believe, "elliptic curve" according to [RFC 4880 section 9.1](https://tools.ietf.org/html/rfc4880#section-9.1) and 22 is EDDSA, according to [draft-koch-eddsa-for-openpgp-04 section 6](https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-04#section-6). Anyways, there's some ECC stuff going on there.
One problem with fixing this is that `openpgp2ssh` has RSA hardcoded all over the place. Even if we would fix that by splitting the RSA code out of `sub findkey` (in `src/share/keytrans`, which is what `openpgp2ssh` eventually calls, i think), we'd still have to actually generate an OpenSSH ed25519 key. And here's the rub: OpenSSL (what eventually backs all of this) doesn't actually support those curves yet. So even if there would be a Perl module to implement this, it wouldn't work because you'd need OpenSSL support.
I tried to implement a converter in Python, using the [PGPy](https://github.com/SecurityInnovation/PGPy/) project, but failed in the same place: it also uses OpenSSL and even though it seems pretty simple to add new curves, there doesn't seem to be an easy way to add that one because support is missing from OpenSSL. I filed a [request to add ED25519](https://github.com/SecurityInnovation/PGPy/issues/221) there to see where it goes. That issue also has details about the OpenSSL implementation, which actually landed in master in June 2017.
Strangely enough, OpenSSH, which *does* use OpenSSL, does implement ed25519. But that's probably thanks to the addition of OpenSSL-free crypto in 2014, which made OpenSSH work without OpenSSL at all...
So anyways, this is as far as I got, basically:
```patch
diff --git a/src/share/keytrans b/src/share/keytrans
index 7b83675..23de61b 100755
--- a/src/share/keytrans
+++ b/src/share/keytrans
@@ -71,6 +71,8 @@ my $old_format_packet_lengths = { one => 0,
my $asym_algos = { rsa => 1,
elgamal => 16,
dsa => 17,
+ cv25519 => 18,
+ ed25519 => 22,
};
# see RFC 4880 section 9.2
```
I'm not even sure those keywords are correct, and they basically don't do anything...https://0xacab.org/monkeysphere/monkeysphere/-/issues/11236Key for signing repos expired2023-08-12T13:39:43ZVladimir VitkovKey for signing repos expiredAs per documentation:
The repository is currently signed by The Monkeysphere archive signing key, key id EB8AF314 (fingerprint: 2E8D D26C 53F1 197D DF40 3E61 18E6 67F1 EB8A F314).
```
~/tmp/monkeysign/monkeysign$ sudo apt-key adv --key...As per documentation:
The repository is currently signed by The Monkeysphere archive signing key, key id EB8AF314 (fingerprint: 2E8D D26C 53F1 197D DF40 3E61 18E6 67F1 EB8A F314).
```
~/tmp/monkeysign/monkeysign$ sudo apt-key adv --keyserver pool.sks-keyservers.net --recv-key 0x2E8DD26C53F1197DDF403E6118E667F1EB8AF314
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /tmp/tmp.z0siTGEXLI --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyring /etc/apt/trusted.gpg.d//jitsi-archive-keyring.gpg --keyserver pool.sks-keyservers.net --recv-key 0x2E8DD26C53F1197DDF403E6118E667F1EB8AF314
gpg: requesting key EB8AF314 from hkp server pool.sks-keyservers.net
gpg: key EB8AF314: public key "Monkeysphere Archive Signing Key (http://archive.monkeysphere.info/debian)" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
```
~/tmp/monkeysign/monkeysign$ sudo apt-get update
.... cut ....
Fetched 45.0 kB in 11s (3,831 B/s)
Reading package lists... Done
W: GPG error: http://archive.monkeysphere.info experimental Release: The following signatures were invalid: KEYEXPIRED 1497742030
```https://0xacab.org/monkeysphere/monkeysphere/-/issues/391posix compliance2023-08-12T13:39:54Zjrollinsposix complianceIt would be nice to make all of the Monkeysphere scripts POSIX compliant, for portability and light-weightedness. Better POSIX compliance would probably at least be better for compatibility with o{ther,lder} versions of bash. Unfortunate...It would be nice to make all of the Monkeysphere scripts POSIX compliant, for portability and light-weightedness. Better POSIX compliance would probably at least be better for compatibility with o{ther,lder} versions of bash. Unfortunately there are quite a few bashism at the moment, so this may not be trivial. For instance:
<pre>
servo:~/cmrg/monkeysphere/git 0$ checkbashisms -f src/monkeysphere-server 2>&1 | wc -l
50
servo:~/cmrg/monkeysphere/git 0$
</pre>
*(from redmine: created on 2008-12-03)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/419ssh config files not parsed2023-08-12T13:39:45Zjrollinsssh config files not parsedIn ~/.ssh/config, i have:
<pre>
HashKnownHosts No
</pre>
But when monkeysphere-ssh-proxycommand adds new hosts to ~/.ssh/known_hosts, they appear to be added in a hashed form, instead of in the clear.
fwiw: i'm using OpenSSH 5.1p1 on a ...In ~/.ssh/config, i have:
<pre>
HashKnownHosts No
</pre>
But when monkeysphere-ssh-proxycommand adds new hosts to ~/.ssh/known_hosts, they appear to be added in a hashed form, instead of in the clear.
fwiw: i'm using OpenSSH 5.1p1 on a debian lenny system (backported from sid)
I can confirm this too (I'm running openssh-client 1:4.7p1-12)
-- Jamie (Jam Jam)
There is absolutely no attempt by any monkeysphere utility to parse any ssh or sshd config file. This will probably need to be delt with down the line, but it's not a particular easy task at the moment.
-- Big Jimmy.
I've posted to the openssh-unix-dev list to see if there is a possibility of openssh making our lives easier here, but i haven't had much of a response yet.
--dkg
For some reason this didn't get mentioned in this bug earlier, but there is a monkeysphere config variable about hashing known_hosts lines, which is set to true by default (to be in sync with the Debian openssh-client package).
I think this bug is really more about the fact that monkeysphere does not parse the ssh config files for any directives relavent to what the monkeysphere is doing. I'm changing the name of this bug to reflect what the real issue is.
-- Big Jimmy.
Posted Sun Oct 26 22:17:52 2008
*(from redmine: created on 2008-12-13)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/443Add man pages to web site2023-08-12T13:39:46ZjrollinsAdd man pages to web siteWe should publish the various monkeysphere man pages in browsable form somewhere under http://web.monkeysphere.info/. Ideally, this would be updated automatically from the sources for the official man pages themselves.
This strikes me a...We should publish the various monkeysphere man pages in browsable form somewhere under http://web.monkeysphere.info/. Ideally, this would be updated automatically from the sources for the official man pages themselves.
This strikes me as an ikiwiki subproject (implementing a man2html wiki compilation language perhaps?).
Interestingly, ikiwiki's own man page appears to be written in markdown and then converted to nroff.
*(from redmine: created on 2008-12-28)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/444MonkeySphere can't deal with passphrase-locked primary keys2023-08-12T13:39:44ZjrollinsMonkeySphere can't deal with passphrase-locked primary keysAt the moment, the only tool we have to export passphrase-locked secret keys from the GPG keyring is gpg itself (and gpg2, which has roughly the same behavior).
As a result, we have the seckey2sshagent hack, which is unfriendly and awkw...At the moment, the only tool we have to export passphrase-locked secret keys from the GPG keyring is gpg itself (and gpg2, which has roughly the same behavior).
As a result, we have the seckey2sshagent hack, which is unfriendly and awkward to use.
Ideally, openpgp2ssh would be able to convert passphrase-locked secret keys into clean subkeys. However, i've tried to do this via GnuTLS, and that library is not ready for this.
OpenCDK, which is the component of GnuTLS which reads OpenPGP-style keys, cannot cope with encrypted secret key material. I have had some success in getting GnuTLS's OpenCDK to accept the existence of encrypted secret key packets, i learned that OpenCDK as included in GnuTLS is incapable of dealing with the encrypted packets themselves.
Some possible resolutions:
If we can assume that the passphrase-encrypted key we want to use is actually a subkey, and if we could fix GnuTLS to ignore the use of the "gnu-dummy S2K" produced by gpg --export-secret-subkeys for the primary key, then something like the following script should actually work for reasonable values of $KEYID:
<pre>
TMPDIR=$(mktemp -d)
umask 077
mkfifo "$TMPDIR/passphrase"
kname="MonkeySphere Key $KEYID"
mkfifo "$TMPDIR/$kname"
ssh-askpass "Please enter the passphrase for MonkeySphere key $KEYID" >"$TMPDIR/passphrase" &
gpg --passphrase-fd 3 3<"$TMPDIR/passphrase" \
--export-options export-reset-subkey-passwd,export-minimal,no-export-attributes \
--export-secret-subkeys "$KEYID"\! | openpgp2ssh "$KEYID" > "$TMPDIR/$kname" &
(cd "$TMPDIR" && ssh-add -c "$kname")
rm -rf "$TMPDIR"
</pre>
*(from redmine: created on 2008-12-28)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/447ssh HostKeyAlias confuses monkeysphere2023-08-12T13:39:44Zjrollinsssh HostKeyAlias confuses monkeysphereConsider the following snippet in ~/.ssh/config:
<pre>
Host foo
HostKeyAlias bar
</pre>
for a host which is not participating in the monkeysphere.
For such a host, when using monkeysphere-ssh-proxy-command, the public keyservers will be...Consider the following snippet in ~/.ssh/config:
<pre>
Host foo
HostKeyAlias bar
</pre>
for a host which is not participating in the monkeysphere.
For such a host, when using monkeysphere-ssh-proxy-command, the public keyservers will be queried on each attempted ssh connection (even after a successful connection).
This appears to be because:
* ssh itself will write a line to ~/.ssh/known_hosts, but it will be labeled with bar because of the HostKeyAlias.
* monkeysphere won't be able to find any mention of it in the keyring (it's not in the monkeysphere)
* monkeysphere-ssh-proxycommand won't be able to find it in the known_hosts file because it looks for foo, which is never matched.
excessive keyserver querying is bad behavior, because it causes delays for the users, and puts excessive load on the public keyserver infrastructure.
How can we resolve this?
*(from redmine: created on 2008-12-28)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/499changes to user authorized_keys files not immediately incorporated2023-08-12T13:39:43Zjrollinschanges to user authorized_keys files not immediately incorporatedIn the current default configuration, the user-controlled authorized_keys file is appended to the end of the monkeysphere-controlled authorized_keys file. However, this is only done when an administrator run the update-users command. T...In the current default configuration, the user-controlled authorized_keys file is appended to the end of the monkeysphere-controlled authorized_keys file. However, this is only done when an administrator run the update-users command. This means that users can add keys to authorized_keys file, but then still not be able to log in with that key until the admin does an update.
We could by default schedule updates, but that still means there would potentially still be an unknown delay for the user.
How do we get around this? "incron":http://inotify.aiken.cz/?section=incron&page=faq&lang=en is a possibility, but it would requires another unusual dependency.
*(from redmine: created on 2009-01-30, relates #500)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/500cron.hourly script needed2023-08-12T13:39:44Zjrollinscron.hourly script neededWe probably need to include a cron.hourly script with the package (/etc/cron.hourly/monkeysphere in Debian). At the moment I can think of two things this script should do:
* run "gpg --refresh-keys" on the monkeysphere gnupg-authenti...We probably need to include a cron.hourly script with the package (/etc/cron.hourly/monkeysphere in Debian). At the moment I can think of two things this script should do:
* run "gpg --refresh-keys" on the monkeysphere gnupg-authentication public keychain
* run "monkeysphere-server update-users" (this is somewhat related to issue #499)
Those things should probably be run in sequence, in that order. Is there anything else we should consider running?
Is there any reason that it would be bad to have the gpg --refresh-keys run every hour? Is this something that we need to be careful about?
*(from redmine: created on 2009-01-30, relates #499)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/625Monkeysphere UI should be internationalized2018-01-09T15:01:05ZdkgMonkeysphere UI should be internationalizedThe monkeysphere's goal is to provide a good, human-focused user interface to the tricky technical problem of networked authentication.
Currently, all of the monkeysphere's UI provides diagnostics, error messages, and user feedback in...The monkeysphere's goal is to provide a good, human-focused user interface to the tricky technical problem of networked authentication.
Currently, all of the monkeysphere's UI provides diagnostics, error messages, and user feedback in english, and there is no framework used to localize the human interaction to other languages.
The monkeysphere UI should be fully internationalized, so that we can adopt localizations if people are willing and able to provide them.
*(from redmine: created on 2009-02-23)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/636monkeysphere user command should be able to import existing ssh keys as OpenP...2018-01-09T15:01:05Zjrollinsmonkeysphere user command should be able to import existing ssh keys as OpenPGP subkeysSimilar to how monkeysphere-host has an import-key function, so should monkeysphere have an import-subkey function, that would take your existing ssh key (~/.ssh/id_rsa for instance) and import it as an authentication-capable subkey to y...Similar to how monkeysphere-host has an import-key function, so should monkeysphere have an import-subkey function, that would take your existing ssh key (~/.ssh/id_rsa for instance) and import it as an authentication-capable subkey to your existing OpenPGP primary key.
*(from redmine: created on 2009-03-07)*1.0https://0xacab.org/monkeysphere/monkeysphere/-/issues/661IPv6 addresses as hostnames are not representable in OpenPGP User ID schema w...2018-01-09T15:01:05ZdkgIPv6 addresses as hostnames are not representable in OpenPGP User ID schema we are usingSince IPv6 addresses are themselves colon-delimited, it's impossible to tell the difference between a server listening on port 2222 on IP @aaaa::bbbb@ from a server listening on the standard port (22) on IP @aaaa::bbbb:2222@, since they ...Since IPv6 addresses are themselves colon-delimited, it's impossible to tell the difference between a server listening on port 2222 on IP @aaaa::bbbb@ from a server listening on the standard port (22) on IP @aaaa::bbbb:2222@, since they would both be represented in the monkeysphere with the same User ID: @ssh://aaaa::bbbb:2222@
OpenSSH deals with this sort of ambiguity by requiring that the host name of non-standard ports be wrapped in square brackets.
This seems like an issue that should be addressed by generic URIs though -- how is this done generally?
Looking at #660, we've never successfully supported alternate ports yet. We have an opportunity to re-define the User ID that we choose to fix this before we release another version, if so desired.
*(from redmine: created on 2009-03-23)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/663Allow for lookup of hashed hostnames in the public keyservers?2018-01-09T15:01:05ZdkgAllow for lookup of hashed hostnames in the public keyservers?Right now, running @monkeysphere update-known_hosts@ with no other arguments tries to update every entry in @~/.ssh/known_hosts@ by pulling from the public keyservers.
However, it skips over all hashed hostnames at the moment.
Do w...Right now, running @monkeysphere update-known_hosts@ with no other arguments tries to update every entry in @~/.ssh/known_hosts@ by pulling from the public keyservers.
However, it skips over all hashed hostnames at the moment.
Do we want to keep that policy? Would there be any reason for us to support looking up hashed hostnames in the public keyservers? Anonymous ssh hostkey lookups somehow? We've talked about supporting this, but haven't walked through all the edge cases yet.
I worry about implying more secrecy than we can really provide. e.g. it would be bad to do a hashed lookup followed by a non-hashed lookup of the same hostname. And it would be absolutely silly for an admin who uploads an OpenPGP certificate with the hashed name as a User ID to also include a non-hashed User ID -- the binding would then be immediately public and easily retrievable.
At any rate, if we continue to ignore hashed known_hosts entries, maybe we want to record how many entries we ignored, and issue some sort of aggregated report at the VERBOSE level or higher, like:
ms: 5 hashed known_hosts entries ignored
*(from redmine: created on 2009-03-24)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/677monkeysphere-authentication update-users could choke when the number of exist...2018-01-09T15:01:05Zdkgmonkeysphere-authentication update-users could choke when the number of existing users is hugecurrently, if you invoke @monkeysphere-authentication update-users@ with no other arguments, it tries to deal with every user on the system.
It does this by slurping in all the user names from the shell, and then doing a @for@ loop ov...currently, if you invoke @monkeysphere-authentication update-users@ with no other arguments, it tries to deal with every user on the system.
It does this by slurping in all the user names from the shell, and then doing a @for@ loop over them.
For systems with a very large number of users, this might not scale properly.
Here's one proposal to handle it that might scale better:
* we could create a pipeline: generate the list of users, one per line, on stdout. feed that list to a series of subprocesses that handle them one at a time.
At the very least, we should probably try to make sure that we know (and can detect) such a failure scenario.
*(from redmine: created on 2009-04-07)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/776deprecate the use of MD-5 and SHA-1 in the monkeysphere2018-01-09T15:01:05Zdkgdeprecate the use of MD-5 and SHA-1 in the monkeysphere"recent results against SHA1":http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf look pretty scary. And "MD5 is even more badly broken":http://www.win.tue.nl/hashclash/rogue-ca/ .
We should ensure that we're using..."recent results against SHA1":http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf look pretty scary. And "MD5 is even more badly broken":http://www.win.tue.nl/hashclash/rogue-ca/ .
We should ensure that we're using something stronger than SHA1 in the monkeysphere, for both hosts and clients. Adoption of SHA-256 or SHA-512 instead would be reasonable.
And while nothing in the monkeysphere uses MD5 explicitly, i believe our key verification relies on MD5 implicitly because "GPG accepts MD5-based signatures":http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024969.html
Unfortunately, there is no current mechanism within gpg to explicitly reject signatures made over any particular digest :( If such a mechanism was to be created, i'd like very much to reject signatures made over an MD5 digest immediately. I don't know when we would need to add SHA-1 to that list, since "a lot of migration work needs to be done first":https://www.debian-administration.org/users/dkg/weblog/48
*(from redmine: created on 2009-05-06)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/917Symlink deference on permission/ownership test2018-01-09T15:01:05ZrhattoSymlink deference on permission/ownership testI'm receiving the following error when trying to ssh to somewhere:
<pre>
ms: improper group or other writability on path '/home/user':
ms: group: w, other:
</pre>
Apparently that happens because:
<pre>
$ ls -l /home/
lrwxr...I'm receiving the following error when trying to ssh to somewhere:
<pre>
ms: improper group or other writability on path '/home/user':
ms: group: w, other:
</pre>
Apparently that happens because:
<pre>
$ ls -l /home/
lrwxrwxrwx 1 user users 23 2009-01-03 15:40 user -> /mnt/crypt/home/user/
</pre>
So maybe monkeysphere needs to deference the symlink and then test the permissions.
*(from redmine: created on 2009-06-07)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/1060document/automate use of monkeysphere with dropbear2018-01-09T15:01:05Zdkgdocument/automate use of monkeysphere with dropbear"dropbear":http://matt.ucc.asn.au/dropbear/ provides a small, functional ssh server and client.
the monkeysphere should be able to work with dropbear servers and clients successfully. we should document what's needed.
For example:..."dropbear":http://matt.ucc.asn.au/dropbear/ provides a small, functional ssh server and client.
the monkeysphere should be able to work with dropbear servers and clients successfully. we should document what's needed.
For example:
to import a dropbear ssh host key into the monkeysphere, do:
/usr/lib/dropbear/dropbearconvert dropbear openssh $host_key_file /dev/fd/1 | monkeysphere-host import-key - $(hostname)
It's not clear how to convince dropbear to use authorized_keys files from somewhere other than ~/.ssh/authorized_keys :(
It's not clear whether dbclient knows how to talk to the ssh-agent.
It's not clear how dbclient implements the equivalent of openssh's known_hosts files.
*(from redmine: created on 2009-07-08)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/1061document/automate use of monkeysphere with lsh2018-01-09T15:01:05Zdkgdocument/automate use of monkeysphere with lsh"lsh":http://www.lysator.liu.se/~nisse/lsh/ is a GNU implementation of the SSH protocol.
we should sort out how to use monkeysphere in conjunction with lsh.
most problematically, lsh appears to use yet another key file format, so w..."lsh":http://www.lysator.liu.se/~nisse/lsh/ is a GNU implementation of the SSH protocol.
we should sort out how to use monkeysphere in conjunction with lsh.
most problematically, lsh appears to use yet another key file format, so we probably need to help the monkeysphere figure out how to deal with it.
*(from redmine: created on 2009-07-08)*