I just noticed: This only happens with an RSA key with 2 sub keys. I just successfully
signed an RSA key with only 1 sub key.

Ok, it gets even funnier. Now I managed to trigger it reliably by having an RSA key
sign my Ed25519 key. Each time I import it, the signature goes from ultimate to undef.
If I import with --import-options import-minimal, it strips all signatures from my
Ed25519 key and the trust goes back to ultimate.

Ok, it seems to be that the problem arises as soon as I sign a key which then in turn
signs me back. If I import a signature and have not signed that key myself, everything
works as expected. But if I then go to sign that key, it goes to undef. If, OTOH, I
sign someone's key and export that, everything is fine. But as soon as they sign me
back, it goes to undef.

Ok, the same seems to happen with just RSA keys. It seems the ultimate trust is killed
as soon as you sign someone who signs you. Increasing priority as a result, as this
means that even without any experimental features, GPG will complain about your own
signatures.

I am not able to repeat that with the latest git version.
This is probably due to the fix by commit c595659.

I applied c595659 manually to 2.1.1, this doesn't change anything.

I'd try it with the latest git master, however I don't see any way to securely check it
out as it is only offered via the insecure git:// protocol.

Here's how to reproduce it:

$ mkdir 1 2
$ chmod 700 1 2
$ cp ~/.gnupg/gpg-agent.conf 1
$ cp ~/.gnupg/gpg-agent.conf 2
$ gpg2 --homedir 1 --yes --quick-gen-key "Test User 1"
gpg: keybox '1/pubring.kbx' created
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: 1/trustdb.gpg: trustdb created
gpg: key E2D6B58A marked as ultimately trusted
gpg: directory '1/openpgp-revocs.d' created
public and secret key created and signed.

gpg: checking the trustdb
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
pub rsa2048/E2D6B58A 2015-01-22

Key fingerprint = E618 DF9C A599 A3A5 D5B2  B8FE 57C0 450E E2D6 B58A

uid [ultimate] Test User 1
sub rsa2048/C3D1C503 2015-01-22

$ gpg2 --homedir 2 --yes --quick-gen-key "Test User 2"
gpg: keybox '2/pubring.kbx' created
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: 2/trustdb.gpg: trustdb created
gpg: key C767617A marked as ultimately trusted
gpg: directory '2/openpgp-revocs.d' created
public and secret key created and signed.

gpg: checking the trustdb
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
pub rsa2048/C767617A 2015-01-22

Key fingerprint = 4741 1B55 ADF9 4000 DFE9  60CF DDF2 7707 C767 617A

uid [ultimate] Test User 2
sub rsa2048/BFC45B68 2015-01-22

$ gpg2 --homedir 1 --export | gpg2 --homedir 2 --import
gpg: key E2D6B58A: public key "Test User 1" imported
gpg: Total number processed: 1
gpg: imported: 1
$ gpg2 --homedir 2 --sign-key E2D6B58A

pub rsa2048/E2D6B58A

created: 2015-01-22  expires: never       usage: SC  
trust: unknown       validity: unknown

sub rsa2048/C3D1C503

created: 2015-01-22  expires: never       usage: E

[ unknown] (1). Test User 1

pub rsa2048/E2D6B58A

created: 2015-01-22  expires: never       usage: SC  
trust: unknown       validity: unknown

Primary key fingerprint: E618 DF9C A599 A3A5 D5B2 B8FE 57C0 450E E2D6 B58A

     Test User 1

Are you sure that you want to sign this key with your
key "Test User 2" (C767617A)

Really sign? (y/N) y

$ gpg2 --homedir 2 --export | gpg2 --homedir 1 --import
gpg: key C767617A: public key "Test User 2" imported
gpg: key E2D6B58A: "Test User 1" 1 new signature
gpg: Total number processed: 2
gpg: imported: 1
gpg: new signatures: 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
$ gpg2 --homedir 1 --list-keys

1/pubring.kbx

pub rsa2048/E2D6B58A 2015-01-22
uid [ultimate] Test User 1
sub rsa2048/C3D1C503 2015-01-22

pub rsa2048/C767617A 2015-01-22
uid [ unknown] Test User 2
sub rsa2048/BFC45B68 2015-01-22

$ # Still ok!
$ gpg2 --homedir 1 --sign-key C767617A

pub rsa2048/C767617A

created: 2015-01-22  expires: never       usage: SC  
trust: unknown       validity: unknown

sub rsa2048/BFC45B68

created: 2015-01-22  expires: never       usage: E

[ unknown] (1). Test User 2

pub rsa2048/C767617A

created: 2015-01-22  expires: never       usage: SC  
trust: unknown       validity: unknown

Primary key fingerprint: 4741 1B55 ADF9 4000 DFE9 60CF DDF2 7707 C767 617A

     Test User 2

Are you sure that you want to sign this key with your
key "Test User 1" (E2D6B58A)

Really sign? (y/N) y

$ gpg2 --homedir 1 --list-keys
gpg: checking the trustdb
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: 1 trust: 1-, 0q, 0n, 0m, 0f, 0u

1/pubring.kbx

pub rsa2048/E2D6B58A 2015-01-22
uid [ undef ] Test User 1
sub rsa2048/C3D1C503 2015-01-22

pub rsa2048/C767617A 2015-01-22
uid [ full ] Test User 2
sub rsa2048/BFC45B68 2015-01-22

$ # Broken!

Okay, I was able to replicate your test case with an older gpg version. I am not
sure which version that was, though. I would need to bisect to find it.

However, with the latest version (commit 09e8f35d3808d6e49f891360c341aae3869e8650)
the problem has gone.

Regarding git: An https:// access is not in any way safer - it only hides what
you are doing on the remote repo. The security from git is due to the chain of
hashes. Thus if you see a full commit id you can be sure that we are talking
about the very same code.

Right, I could have given the full commit id, but that won't help either because
you should not trust this bug tracker. The only reliabale task is by starting
from a signed commit or tag and review all code up to there.
Fortunately any tmapering with git.gnupg.org would soon trigger a lot of
complains from people pulling updates and checking commit ids.

Ok, I'll give it a try with 09e8f35d3808d6e49f891360c341aae3869e8650 this weekend.

Regarding https: Yes, this is more security, even though only slightly as you will have
to trust CAs. Without it, an attacker could just give you a different repo and you'd
never notice if you don't compare commit checksums with someone else. Then again, that
someone else could also get the wrong repo, because your government decided that
everybody should get a backdoor'd GPG. With https, you also need to get a valid
certificate that's in the CAs. That's not helping against a government wanting to
backdoor GPG, but it at least helps against script kiddies and the like.

Speaking about signed commits and tags: Why not do that? I tried it with git and it
works great.

All release tags are signed.

Signed commits are a bit cumbersome becuase I would have to insert the smartcard
for all commits. Signing with my on-disk standard key would be possible, though.

May I assume this problem has been fixed?

(BTW, I sign my commits now)

Yes, this is fixed. Sorry for forgetting to update this bug. Already noticed your
commits are signed - unfortunately, your commit signing key isn't signed by any other
of your keys, though.