no valid OpenPGP data found when trying to add repositories on ubuntu

[arashmo]

sudo add-apt-repository ppa:graphics-drivers/ppa

gpg: keyring /tmp/tmpm22_n592/secring.gpg' created gpg: keyring/tmp/tmpm22_n592/pubring.gpg' created gpg: requesting key 1118213C from hkp server keyserver.ubuntu.com gpgkeys: key 2388FF3BE10A76F638F80723FCAE110B1118213C can't be retrieved gpg: no valid OpenPGP data found. gpg: Total number processed: 0 gpg: keyserver communications error: keyserver helper general error gpg: keyserver communications error: unknown pubkey algorithm gpg: keyserver receive failed: unknown pubkey algorithm Failed to add key.

tailf /var/log/syslog Mar 4 12:07:49 m84116293-HP-ProDesk-600-G3-PCI-MT alpaca[21627]: 2020/03/04 12:07:49 proxyfinder.go:92: [3408] CONNECT //launchpad.net:443 via "PROXY proxy.lan:8080 " Mar 4 12:07:51 m84116293-HP-ProDesk-600-G3-PCI-MT alpaca[21627]: 2020/03/04 12:07:51 proxyfinder.go:92: [3409] CONNECT //launchpad.net:443 via "PROXY proxy.lan:8080 " Mar 4 12:07:51 m84116293-HP-ProDesk-600-G3-PCI-MT alpaca[21627]: 2020/03/04 12:07:51 proxyfinder.go:92: [3410] GET http://keyserver.ubuntu.com:80/pks/lookup?op=get&options=mr&search=0x2388FF3BE10A76F638F80723FCAE110B1118213C via "PROXY proxy.lan:8080 "

[camh-]

I am able to successfully retrieve the URL http://keyserver.ubuntu.com:80/pks/lookup?op=get&options=mr&search=0x2388FF3BE10A76F638F80723FCAE110B1118213C via alpaca. Perhaps this is a problem with your proxy (proxy.lan:8080) ?

[samuong]

It's possible that, for whatever reason, alpaca is failing to authenticate to proxy.lan:8080 (this could be because of a bug in alpaca, but could also be an issue with the proxy server or your proxy configuration). What do you get when you run the following command?

curl -D- 'http://keyserver.ubuntu.com/pks/lookup?op=get&options=mr&search=0x2388FF3BE10A76F638F80723FCAE110B1118213C'

[arashmo]

so weird when i do curl -D- http://key-server the certs just get printed on the screen and if immediately do add-apt-repositories the key also get imported.

i think something is wrong with ntlm authentication and the way apt-add-repositories works, i just tried to print the packets content using wireshark i figured out that i get company access denied page instead of certificate when i used add-apt-repositories

curl -D- 'http://keyserver.ubuntu.com/pks/lookup?op=get&options=mr&search=0x2388FF3BE10A76F638F80723FCAE110B1118213C' HTTP/1.1 200 OK Content-Type: text/plain Date: Thu, 05 Mar 2020 19:13:30 GMT Proxy-Connection: Keep-Alive Server: Apache/2.4.29 (Ubuntu) Via: proxy A Transfer-Encoding: chunked

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFXLUXIBEADggY4UTKq5jU0lYFAzC4g7iB50aRgJRA+nL9NkrHamdtNggfVy wzflQYJ4w96FV5p5j+9Nvdfk5ZPHe+uVmaC5AUdId2G+zzG/fsf3Ri9hz61sYg4M 8DyRZDh9KLqr+x7AazAHjmqwLecT/sNHdwHFdduQcvvkwfMw8JUN6IIRrbT3ISoZ gaktuF8EfFuc/PKoCoHWXjgVqw/JDjpL/1LHyMwYWfZgrG41PqRSxI9/dKt0W7XX dOEckHTjV6IZkVCYCBMcObM2ZLSMVb0u9SlTOUIHaF3A2IY+9RLpUAa8bZLodiXa lfQ9OmvQm+eIXOedzBhs2z7hGBJwcCGW94cVygWUyakfsxCqPF4+VJHKnEgp/kkP

[arashmo]

what i found is that it does the ntlm-auth at beginning and once to get into import key it sends the packet without auth

[samuong]

If alpaca fails to do the ntlm auth with the proxy, I would expect you to get a 407 (proxy auth required) rather than a 200 (ok) response. So it looks like, if the proxy is requiring authentication, alpaca is doing it.

How have you configured your proxy settings for curl and add-apt-repository? If you followed the instructions in the README, you might've done something like export http_proxy=http://localhost:3128. If you run curl, it'll pick this up from your environment. But if you run sudo add-apt-repository, I don't think sudo will pass the http_proxy variable to add-apt-repository.

I'm not sure if I've explained this very clearly, so maybe this gives an idea of what I mean:

sam@sams-macbook-air:~$ export http_proxy=http://localhost:3128
sam@sams-macbook-air:~$ cat whatproxy
#!/bin/sh
echo http_proxy="$http_proxy"
sam@sams-macbook-air:~$ ./whatproxy  # <-- this is like how you invoke curl
http_proxy=http://localhost:3128
sam@sams-macbook-air:~$ sudo ./whatproxy  # <-- this is like how you invoke add-apt-repository
http_proxy=
sam@sams-macbook-air:~$ sudo http_proxy=http://localhost:3128 ./whatproxy 
http_proxy=http://localhost:3128

tl;dr - can you try running the following command and let me know how it goes?

sudo http_proxy=http://localhost:3128 add-apt-repository ppa:graphics-drivers/ppa

[arashmo]

i just rechecked everything again, it seems that when i do curl -D- will get the right certificates but ad-apt-repositories fails to do the NTML authentication, there must be something wrong with connection flow as i see on my wireshark connection get closed and once openned again it gets access denied from my proxy server . git also has an issue with it !!

Cloning into 'loopback-next'... remote: Enumerating objects: 9, done. remote: Counting objects: 100% (9/9), done. remote: Compressing objects: 100% (9/9), done. remote: Total 70230 (delta 3), reused 0 (delta 0), pack-reused 70221 Receiving objects: 100% (70230/70230), 52.55 MiB | 6.46 MiB/s, done. error: RPC failed; curl 56 GnuTLS recv error (-110): The TLS connection was non-properly terminated. Resolving deltas: 100% (56607/56607), done.

by the way I have CNTLM running on my local system and it works perfectly

$ ./whatproxy.sh http_proxy=http://localhost:3129 $ sudo ./whatproxy.sh http_proxy=http://localhost:3129

[samuong]

That's really strange. It's hard for me to guess what's going on without knowing exactly what you've done and how you've got things set up. Can you please include the following?

1. Exactly what git command did you run?
2. How did you configure git to route traffic via alpaca? (was it via http_proxy/https_proxy, did you put that in .bashrc/.bash_profile or did you just set it in the session, did you set no_proxy as well, did you use git-config, etc.)
3. What's in the alpaca log?
4. Anything else that you think might be useful, like screenshots of what you're seeing in wireshark and/or what proxy your network has

[arashmo]

hi dear samoung this is what i get, i am 100 percent sure my proxy setting is right, every single time i try to run any command i check my env and if its sudo i check it from root .

2020/03/10 18:52:02 proxyfinder.go:92: [13] CONNECT //launchpad.net:443 via "PROXY proxy.lan:8080; DIRECT" 2020/03/10 18:52:02 proxyfinder.go:95: [13] Warning: ignoring all but first proxy in "PROXY proxy.lan:8080; DIRECT" 2020/03/10 18:52:20 proxyfinder.go:92: [14] GET http://keyserver.ubuntu.com:80/pks/lookup?op=get&options=mr&search=0x2388FF3BE10A76F638F80723FCAE110B1118213C via "PROXY proxy.lan:8080; DIRECT" 2020/03/10 18:52:20 proxyfinder.go:95: [14] Warning: ignoring all but first proxy in "PROXY proxy.lan:8080; DIRECT" 2020/03/10 18:52:22 proxyfinder.go:92: [15] CONNECT //getpocket.cdn.mozilla.net:443 via "PROXY proxy.lan:8080; DIRECT" 2020/03/10 18:52:22 proxyfinder.go:95: [15] Warning: ignoring all but first proxy in "PROXY proxy.lan:8080; DIRECT" 2020/03/10 18:52:30 proxyfinder.go:92: [14] GET http://keyserver.ubuntu.com:80/pks/lookup?op=get&options=mr&search=0x2388FF3BE10A76F638F80723FCAE110B1118213C via "PROXY proxy.lan:8080; DIRECT" 2020/03/10 18:52:30 proxyfinder.go:95: [14] Warning: ignoring all but first proxy in "PROXY proxy.lan:8080; DIRECT" 2020/03/10 18:52:40 proxyfinder.go:92: [14] GET http://keyserver.ubuntu.com:80/pks/lookup?op=get&options=mr&search=0x2388FF3BE10A76F638F80723FCAE110B1118213C via "PROXY proxy.lan:8080; DIRECT" 2020/03/10 18:52:40 proxyfinder.go:95: [14] Warning: ignoring all but first proxy in "PROXY proxy.lan:8080; DIRECT"

[samuong]

I can't reproduce your error, even if I hack Alpaca to always return a 407. Without knowing how you've configured your proxy and exactly how you ran git/add-apt-repository/whatever else, there's no way for me to reproduce what you're getting and investigate further. I'm sure you believe you've done this correctly, but can you share the details with me anyway?

One thing that I noticed is that there are 6 log lines with the sequence number "[14]" in it, 2 lines per request. It looks an awful lot like it's running through an NTLM handshake, which is a 3-step process. These steps are:

1. The initial request, in proxy.go:184, that tries the initial request without credentials. It's likely that proxy.lan:8080 is returning a 407 here.
2. The "type 1" message, in authenticator.go:82, which initiates the NTLM handshake. The proxy should respond with a "type 2" message.
3. Alpaca then sends a "type 3" message, in authenticator.go:103, which is the final message in the handshake.

This means that Alpaca is doing the NTLM handshake. It's not clear whether this succeeded or not, but it definitely gets all the way to the end. I can think of two reasons it might not succeed:

1. Your proxy only supports an old version of NTLM. Cntlm supports a wide range of NTLM versions, whereas Alpaca uses http://github.com/Azure/go-ntlmssp, which only supports NTLMv2.
2. You mentioned in #48 that you modified Alpaca to grab your credentials from a text file so that you could run it from a systemd unit. It's possible that the credentials are still not being picked up correctly - can you please try this with an unmodified version of Alpaca with the password typed in to the console, and let us know whether this works?

It's also interesting that these requests all happen exactly 10 seconds apart - at 18:52:20, 18:52:30 and 18:52:40. I don't know whether this means anything, but it seems odd.

[samuong]

Closing this as we're unable to reproduce this on our end, and it's unclear whether this is an issue with Alpaca or the upstream proxy. Please feel free to reopen if it you can provide more info on how to reproduce it.