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/392use getopts instead of getopt2017-04-01T09:46:58Zjrollinsuse getopts instead of getoptSince Monkeysphere is using bash, it would be nice to use the shell build in getopts function, instead of the external getopt program. This would reduce an external dependency, which would definitely be better for portability.
*(from re...Since Monkeysphere is using bash, it would be nice to use the shell build in getopts function, instead of the external getopt program. This would reduce an external dependency, which would definitely be better for portability.
*(from redmine: created on 2008-12-03, closed on 2008-12-28)*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/420Problems with root-owned gpg keyrings2017-04-01T09:46:59ZjrollinsProblems with root-owned gpg keyrings/var/lib/monkeysphere/gnupg-host/ is root-owned, and the public keyring in that directory is controlled by the superuser.
We currently expect the monkeysphere user to read from (but not write to) that keyring. But using a keyring in a.../var/lib/monkeysphere/gnupg-host/ is root-owned, and the public keyring in that directory is controlled by the superuser.
We currently expect the monkeysphere user to read from (but not write to) that keyring. But using a keyring in a directory that you don't control appears to trigger a subtle bug in gpg that has been unresolved for quite a long time.
With some of the new error checking i'm doing in monkeysphere-server, typical operations that involve both keyrings as the non-privileged user can fail with an error message like:
<pre>
gpg: failed to rebuild keyring cache: file open error
</pre>
Running the relevant operation a second time as the same user usually lets things go through without a failure, but this seems like it would be hiding a bug, rather than getting it fixed correctly.
Are there other ways we can deal with this problem?
--dkg
Here is an example when using monkeysphere-server add-identity-certifier on a host with a newly-installed monkeysphere installaton. Note that running the same command a second time works as expected:
<pre>
0 pip:~# monkeysphere-server c+ 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
gpg: requesting key D21739E9 from hkp server pool.sks-keyservers.net
gpg: key D21739E9: public key "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" imported
gpg: can't create `/var/lib/monkeysphere/gnupg-host/pubring.gpg.tmp': Permission denied
gpg: failed to rebuild keyring cache: file open error
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2009-03-30
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
Could not receive a key with this ID from the 'pool.sks-keyservers.net' keyserver.
255 pip:~# monkeysphere-server c+ 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
gpg: requesting key D21739E9 from hkp server pool.sks-keyservers.net
gpg: key D21739E9: "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
key found:
pub 4096R/D21739E9 2007-06-02 [expires: 2012-05-31]
Key fingerprint = 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9
uid [ unknown] Daniel Kahn Gillmor <dkg@fifthhorseman.net>
uid [ unknown] Daniel Kahn Gillmor <dkg@openflows.com>
uid [ unknown] Daniel Kahn Gillmor <dkg@astro.columbia.edu>
uid [ unknown] Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net>
uid [ unknown] [jpeg image of size 3515]
sub 2048R/4BFA08E4 2008-06-19 [expires: 2009-06-19]
sub 4096R/21484CFF 2007-06-02 [expires: 2012-05-31]
Are you sure you want to add the above key as a
certifier of users on this system? (y/N) y
gpg: key D21739E9: public key "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2009-03-30
gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
pub 4096R/D21739E9 created: 2007-06-02 expires: 2012-05-31 usage: SC
trust: unknown validity: unknown
[ unknown] (1). Daniel Kahn Gillmor <dkg@fifthhorseman.net>
[ unknown] (2) Daniel Kahn Gillmor <dkg@openflows.com>
[ unknown] (3) Daniel Kahn Gillmor <dkg@astro.columbia.edu>
[ unknown] (4) Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net>
[ unknown] (5) [jpeg image of size 3515]
pub 4096R/D21739E9 created: 2007-06-02 expires: 2012-05-31 usage: SC
trust: unknown validity: unknown
Primary key fingerprint: 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9
Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Daniel Kahn Gillmor <dkg@openflows.com>
Daniel Kahn Gillmor <dkg@astro.columbia.edu>
Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net>
[jpeg image of size 3515]
This key is due to expire on 2012-05-31.
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I trust marginally
2 = I trust fully
Please enter the depth of this trust signature.
A depth greater than 1 allows the key you are signing to make
trust signatures on your behalf.
Please enter a domain to restrict this signature, or enter for none.
Are you sure that you want to sign this key with your
key "ssh://pip.fifthhorseman.net" (9B83C17D)
The signature will be marked as non-exportable.
gpg: can't create `/var/lib/monkeysphere/gnupg-host/pubring.gpg.tmp': Permission denied
gpg: failed to rebuild keyring cache: file open error
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 1f, 0u
gpg: next trustdb check due at 2009-03-30
Identity certifier added.
0 pip:~#
</pre>
*(from redmine: created on 2008-12-13, closed on 2009-02-17)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/421make tarball is not idempotent2017-04-01T09:46:59Zjrollinsmake tarball is not idempotentThe current monkeysphere Makefile has a "tarball" target, which produces the "upstream tarball". Unfortunately, it is not idempotent. That is, if you run it twice in a row (without changing any other source), the second .orig.tar.gz file...The current monkeysphere Makefile has a "tarball" target, which produces the "upstream tarball". Unfortunately, it is not idempotent. That is, if you run it twice in a row (without changing any other source), the second .orig.tar.gz file is bytewise different from the first.
We should fix this so that the tarball generated is the same at least as long as no local file has been touched.
*(from redmine: created on 2008-12-13, closed on 2009-07-11)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/422revoke-hostname function revokes wrong hostname user ID2017-04-01T09:46:59Zjrollinsrevoke-hostname function revokes wrong hostname user IDIt appears that the monkeysphere-server revoke-hostname function will occasionaly revoke the wrong hostname. I say occasionally, but it seems to be doing it pretty consistently for me at the moment:
<pre>
servo:~ 0$ sudo monkeysphere-s...It appears that the monkeysphere-server revoke-hostname function will occasionaly revoke the wrong hostname. I say occasionally, but it seems to be doing it pretty consistently for me at the moment:
<pre>
servo:~ 0$ sudo monkeysphere-server n- servo.finestructure.net
The following host key user ID will be revoked:
ssh://servo.finestructure.net
Are you sure you would like to revoke this user ID? (y/N) y
gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub 1024R/9EEAC276 created: 2008-07-10 expires: never usage: CA
trust: ultimate validity: ultimate
[ultimate] (1) ssh://localhost.localdomain
[ultimate] (2). ssh://servo.finestructure.net
[ revoked] (3) ssh://jamie.rollins
[ revoked] (4) asdfsdflkjsdf
[ revoked] (5) ssh://asdfsdlf.safsdf
[ revoked] (6) ssh://bar.baz
[ revoked] (7) ssh://foo.bar
[ revoked] (8) ssh://
pub 1024R/9EEAC276 created: 2008-07-10 expires: never usage: CA
trust: ultimate validity: ultimate
[ultimate] (1)* ssh://localhost.localdomain
[ultimate] (2). ssh://servo.finestructure.net
[ revoked] (3) ssh://jamie.rollins
[ revoked] (4) asdfsdflkjsdf
[ revoked] (5) ssh://asdfsdlf.safsdf
[ revoked] (6) ssh://bar.baz
[ revoked] (7) ssh://foo.bar
[ revoked] (8) ssh://
Please select the reason for the revocation:
0 = No reason specified
4 = User ID is no longer valid
Q = Cancel
(Probably you want to select 4 here)
Enter an optional description; end it with an empty line:
Reason for revocation: User ID is no longer valid
Hostname removed by monkeysphere-server 2008-08-16T17:34:02
pub 1024R/9EEAC276 created: 2008-07-10 expires: never usage: CA
trust: ultimate validity: ultimate
[ revoked] (1) ssh://localhost.localdomain
[ultimate] (2). ssh://servo.finestructure.net
[ revoked] (3) ssh://jamie.rollins
[ revoked] (4) asdfsdflkjsdf
[ revoked] (5) ssh://asdfsdlf.safsdf
[ revoked] (6) ssh://bar.baz
[ revoked] (7) ssh://foo.bar
[ revoked] (8) ssh://
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 2 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 2f, 0u
gpg: next trustdb check due at 2012-01-07
sec 1024R/9EEAC276 2008-07-10
Key fingerprint = C094 43E0 6882 8BE2 E9AD 516C 45CF 974D 9EEA C276
uid ssh://servo.finestructure.net
uid [ revoked] ssh://localhost.localdomain
uid [ revoked] ssh://jamie.rollins
uid [ revoked] asdfsdflkjsdf
uid [ revoked] ssh://asdfsdlf.safsdf
uid [ revoked] ssh://bar.baz
uid [ revoked] ssh://foo.bar
uid [ revoked] ssh://
NOTE: User ID revoked, but revokation not published.
Run 'monkeysphere-server publish-key' to publish the revocation.
servo:~ 0$
</pre>
Clearly this is unacceptable. gpg does not let you specify a uid to revoke from the command line. The uid revocation can only be done through edit-key. We do edit-key scripting in other contexts, but to revoke a user id you have to specify the uid by "number". We currently try to guess the number from the ordering of the output of list-key. However, this output does not appear to coincide with the ordering in edit-key. I don't have a good solution or fix at the moment. Suggestions are most welcome. It may just require some trial and error with edit-key to come up with something workable.
This underlines the problem that gpg is currently not very well suited for manipulating gpg keyrings non-interactively. It's possible that I just haven't figured out how to do it yet, but it's not very clear if it is possible. It would be nice to have some alternate tools to use.
*(from redmine: created on 2008-12-13, closed on 2009-07-14)*0.25dkgdkghttps://0xacab.org/monkeysphere/monkeysphere/-/issues/438monkeysphere and monkeysphere-server should be able to report version informa...2017-04-01T09:46:59Zdkgmonkeysphere and monkeysphere-server should be able to report version informationcurrently, monkeysphere help and monkeysphere-server help do not report the version of the tool. i think it would be useful to us (for future debugging help on remote installations, if nothing else) to be able to quickly know what versi...currently, monkeysphere help and monkeysphere-server help do not report the version of the tool. i think it would be useful to us (for future debugging help on remote installations, if nothing else) to be able to quickly know what version of monkeysphere is in use.
*(from redmine: created on 2008-12-26, closed on 2009-03-02)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/439proposed new monkeysphere-server subcommand: setup2017-04-01T09:46:59Zjrollinsproposed new monkeysphere-server subcommand: setupWhat if everything that's done in the package post-installation scripts (aside from maybe the creation of the monkeysphere user itself) was done with a single call to something like
<pre>
monkeysphere-server setup
</pre>
This would m...What if everything that's done in the package post-installation scripts (aside from maybe the creation of the monkeysphere user itself) was done with a single call to something like
<pre>
monkeysphere-server setup
</pre>
This would make things more obvious to folks installing from source directly, and put less maintenance load on porters. The end of monkeysphere-server setup could also invoke monkeysphere-server diagnostics to get the admin pointed in the right direction.
Think of this as a sort of automated "Getting Started" documentation.
Of course, a hypothetical full setup command would do things like gen-key, auto-modify sshd_config, etc. We wouldn't want to do those things automatically without the guiding hand of the local sysadmin.
But perhaps we could even smooth that process with:
<pre>
monkeysphere-server setup --full
</pre>
I'd like to know what other folks think about these possibilities. Would either of these be useful? Are they confusing? Could they be clarified?
*(from redmine: created on 2008-12-28, closed on 2009-02-17)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/440Monkeysphere should support authorized_keys options in authorized_user_ids files2017-04-01T09:46:59ZjrollinsMonkeysphere should support authorized_keys options in authorized_user_ids filesOpenSSH allows users to control the capabilities granted to remote key-based logins by supplying options that should limit the use of the key.
For example, specifying no-pty means that sshd should not allocate a pseudo-terminal for se...OpenSSH allows users to control the capabilities granted to remote key-based logins by supplying options that should limit the use of the key.
For example, specifying no-pty means that sshd should not allocate a pseudo-terminal for sessions created based on an authentication with that key.
It is unclear if it is possible to do this sort of limiting in ~/.monkeysphere/authorized_user_ids, and if it is possible, how you'd actually do it.
*(from redmine: created on 2008-12-28, closed on 2010-10-04)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/441monkeysphere gen-subkey treats revoked auth subkey as valid2017-04-01T09:46:59Zjrollinsmonkeysphere gen-subkey treats revoked auth subkey as validIf you have a revoked authentication subkey in your keyring, monkeysphere gen-subkey thinks that I have an authentication subkey already, which I do, but it probably shouldn't care about it, since it is revoked:
<pre>
21:30@pond> monke...If you have a revoked authentication subkey in your keyring, monkeysphere gen-subkey thinks that I have an authentication subkey already, which I do, but it probably shouldn't care about it, since it is revoked:
<pre>
21:30@pond> monkeysphere gen-subkey F67E2A5D1CF2D62A
An authentication subkey already exists for key 'F67E2A5D1CF2D62A'.
Are you sure you would like to generate another one? (y/N)
</pre>
However: this key was revoked on 2008-04-28 by DSA key 1CF2D62A Micah Anderson micah@riseup.net sub 1024R/866F47D3 created: 2008-02-25 revoked: 2008-04-28 usage: A
I can continue to create a new authorization subkey, so its not a blocker or anything (I suppose I could also delete the revoked key from my keyring as well, although thats less than ideal).
It seems like the secret keyring doesn't mention that it has been revoked, so probably monkeysphere needs to be looking at gpg's computed validity from the public keyring instead of the secret keyring to be able to get the "r" flag from field 2, in addition to the "e" flag from field 12.
*(from redmine: created on 2008-12-28, closed on 2008-12-31)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/442authentication gpg_sphere function requires single input2017-04-01T09:46:59Zjrollinsauthentication gpg_sphere function requires single inputIn monkeysphere-authentication, the gpg_sphere function, which is run as the monkeysphere user with su, currently requires that all arguments be put in a single quoted argument, eg:
<pre>
gpg_sphere "--list-key --with-colons --with-fin...In monkeysphere-authentication, the gpg_sphere function, which is run as the monkeysphere user with su, currently requires that all arguments be put in a single quoted argument, eg:
<pre>
gpg_sphere "--list-key --with-colons --with-fingerprint 0x${keyID}!"
</pre>
This is obviously a little lame, but it seems to be necessary to do the necessary argument passing from the function, to the su function called as the monkeysphere user that controls the gpg sphere keyring.
I'm not sure how to fix it. I think the problem is mostly in how arguments are passed to su.
This also affects the ms-authentication gpg-cmd function, since it calls this internally.
*(from redmine: created on 2008-12-28, closed on 2010-10-04)*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/445Running `monkeysphere gen-key` on a headless server takes way too long2017-04-01T09:46:59ZjrollinsRunning `monkeysphere gen-key` on a headless server takes way too longWhen i try to generate a key on a headless machine (no kbd, no mouse, no Human Input Device (HID) at all), monkeysphere gen-key hangs for a very long time (over an hour so far!) during the generation process, particularly at this point:
...When i try to generate a key on a headless machine (no kbd, no mouse, no Human Input Device (HID) at all), monkeysphere gen-key hangs for a very long time (over an hour so far!) during the generation process, particularly at this point:
<pre>
ms: generating server key...
Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 197 more bytes)
</pre>
And sure enough, there really is very little entropy in these systems at the time requested:
<pre>
0 chomsky:~# cat /proc/sys/kernel/random/entropy_avail
32
0 chomsky:~#
</pre>
It's not clear to me how to increase the entropy available to the kernel without an HID.
I've seen this happen on two machines now in the last week, and was able to resolve it on the first one by plugging in a keyboard and "massaging" it. This won't work for a machine that's out of physical range, and has no keyboard to be plugged in anyway.
One thing that might help is to suggest that the system administrator install a package like bsdgames and play console-based games as a non-privileged user, since that seems to feed the entropy count somewhat.
*(from redmine: created on 2008-12-28, closed on 2009-02-17)*https://0xacab.org/monkeysphere/monkeysphere/-/issues/446add-identity-certifier behaves oddly without pty2017-04-01T09:46:59Zjrollinsadd-identity-certifier behaves oddly without ptyWhen executing monkeysphere-server add-identity-certifier across a link without a pseudo-terminal, it behaves oddly (prompts are created that are only halfway-readable, gpg gives error messages about lacking access to a /dev/tty, etc.
...When executing monkeysphere-server add-identity-certifier across a link without a pseudo-terminal, it behaves oddly (prompts are created that are only halfway-readable, gpg gives error messages about lacking access to a /dev/tty, etc.
You can try this directly if you have remote ssh access to the superuser on a monkeysphere-enabled host, assuming that $GPGID is set to the full fingerprint of a key you want to add as a trusted identity certifier:
<pre>
ssh root@example.org monkeysphere-server add-identity-certifier $GPGID
</pre>
Compare this behavior with:
<pre>
ssh -t root@example.org monkeysphere-server add-identity-certifier $GPGID
</pre>
*(from redmine: created on 2008-12-28, closed on 2009-07-11)*0.25https://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)*