[arch-general] pacman-key complaining, but what to do about it?
On a newly set up system I've added the [haskell-core] repo [1], but get stuck with the following message from `pacman`: ~~~~ % sudo pacman -Syy error: haskell-testing: signature from "ArchHaskell (Magnus Therning) <magnus@therning.org>" is invalid :: Synchronising package databases... core 108.2 KiB 1335K/s 00:00 [##############################################] 100% haskell-testing.sig 96.0 B 0.00B/s 00:00 [##############################################] 100% error: haskell-testing: signature from "ArchHaskell (Magnus Therning) <magnus@therning.org>" is invalid error: failed to update haskell-testing (invalid or corrupted database (PGP signature)) extra 1565.7 KiB 1947K/s 00:01 [##############################################] 100% community 2.1 MiB 1735K/s 00:01 [##############################################] 100% multilib 115.3 KiB 1746K/s 00:00 [##############################################] 100% error: database 'haskell-testing' is not valid (invalid or corrupted database (PGP signature)) ~~~~ I've read [2] and verified (to the best of my ability) that I have correct time settings. I've also tried resetting the keys, but that doesn't improve the situation either. What else could it be? How do I find out? What can I do about it? /M [1]: https://wiki.archlinux.org/index.php/Haskell_package_guidelines [2]: https://wiki.archlinux.org/index.php/Pacman-key#Troubleshooting -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On Wed, Apr 2, 2014 at 9:32 AM, Magnus Therning <magnus@therning.org> wrote:
On a newly set up system I've added the [haskell-core] repo [1], but get stuck with the following message from `pacman`:
~~~~ % sudo pacman -Syy error: haskell-testing: signature from "ArchHaskell (Magnus Therning) <magnus@therning.org>" is invalid :: Synchronising package databases... core 108.2 KiB 1335K/s 00:00 [##############################################] 100% haskell-testing.sig 96.0 B 0.00B/s 00:00 [##############################################] 100% error: haskell-testing: signature from "ArchHaskell (Magnus Therning) <magnus@therning.org>" is invalid error: failed to update haskell-testing (invalid or corrupted database (PGP signature)) extra 1565.7 KiB 1947K/s 00:01 [##############################################] 100% community 2.1 MiB 1735K/s 00:01 [##############################################] 100% multilib 115.3 KiB 1746K/s 00:00 [##############################################] 100% error: database 'haskell-testing' is not valid (invalid or corrupted database (PGP signature)) ~~~~
I've read [2] and verified (to the best of my ability) that I have correct time settings. I've also tried resetting the keys, but that doesn't improve the situation either.
What else could it be? How do I find out? What can I do about it?
I think I've found the reason for it: ~~~~ community.db: gzip compressed data, last modified: Wed Apr 2 04:23:21 2014, from Unix core.db: gzip compressed data, last modified: Tue Apr 1 19:08:44 2014, from Unix extra.db: gzip compressed data, last modified: Wed Apr 2 01:09:14 2014, from Unix haskell-testing.db: POSIX tar archive multilib.db: gzip compressed data, last modified: Wed Apr 2 05:12:37 2014, from Unix ~~~~ Where and why would un-gzipping strike like this? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On Wed, Apr 02, 2014 at 10:16:04AM +0200, Magnus Therning wrote:
On Wed, Apr 2, 2014 at 9:32 AM, Magnus Therning <magnus@therning.org> wrote:
On a newly set up system I've added the [haskell-core] repo [1], but get stuck with the following message from `pacman`:
~~~~ % sudo pacman -Syy error: haskell-testing: signature from "ArchHaskell (Magnus Therning) <magnus@therning.org>" is invalid :: Synchronising package databases... core 108.2 KiB 1335K/s 00:00 [##############################################] 100% haskell-testing.sig 96.0 B 0.00B/s 00:00 [##############################################] 100% error: haskell-testing: signature from "ArchHaskell (Magnus Therning) <magnus@therning.org>" is invalid error: failed to update haskell-testing (invalid or corrupted database (PGP signature)) extra 1565.7 KiB 1947K/s 00:01 [##############################################] 100% community 2.1 MiB 1735K/s 00:01 [##############################################] 100% multilib 115.3 KiB 1746K/s 00:00 [##############################################] 100% error: database 'haskell-testing' is not valid (invalid or corrupted database (PGP signature)) ~~~~
I've read [2] and verified (to the best of my ability) that I have correct time settings. I've also tried resetting the keys, but that doesn't improve the situation either.
What else could it be? How do I find out? What can I do about it?
I think I've found the reason for it:
~~~~ community.db: gzip compressed data, last modified: Wed Apr 2 04:23:21 2014, from Unix core.db: gzip compressed data, last modified: Tue Apr 1 19:08:44 2014, from Unix extra.db: gzip compressed data, last modified: Wed Apr 2 01:09:14 2014, from Unix haskell-testing.db: POSIX tar archive multilib.db: gzip compressed data, last modified: Wed Apr 2 05:12:37 2014, from Unix ~~~~
Where and why would un-gzipping strike like this?
And now I've confirmed that this un-gzipping doesn't happen on my private computer at home. So, what's causing this un-gzipping of the downloaded repo db, I wonder? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay
Am 02.04.2014 17:56, schrieb Magnus Therning:
On Wed, Apr 2, 2014 at 9:32 AM, Magnus Therning <magnus@therning.org> wrote:
On a newly set up system I've added the [haskell-core] repo [1], but get stuck with the following message from `pacman`:
~~~~ % sudo pacman -Syy error: haskell-testing: signature from "ArchHaskell (Magnus Therning) <magnus@therning.org>" is invalid :: Synchronising package databases... core 108.2 KiB 1335K/s 00:00 [##############################################] 100% haskell-testing.sig 96.0 B 0.00B/s 00:00 [##############################################] 100% error: haskell-testing: signature from "ArchHaskell (Magnus Therning) <magnus@therning.org>" is invalid error: failed to update haskell-testing (invalid or corrupted database (PGP signature)) extra 1565.7 KiB 1947K/s 00:01 [##############################################] 100% community 2.1 MiB 1735K/s 00:01 [##############################################] 100% multilib 115.3 KiB 1746K/s 00:00 [##############################################] 100% error: database 'haskell-testing' is not valid (invalid or corrupted database (PGP signature)) ~~~~
I've read [2] and verified (to the best of my ability) that I have correct time settings. I've also tried resetting the keys, but that doesn't improve the situation either.
What else could it be? How do I find out? What can I do about it? I think I've found the reason for it:
~~~~ community.db: gzip compressed data, last modified: Wed Apr 2 04:23:21 2014, from Unix core.db: gzip compressed data, last modified: Tue Apr 1 19:08:44 2014, from Unix extra.db: gzip compressed data, last modified: Wed Apr 2 01:09:14 2014, from Unix haskell-testing.db: POSIX tar archive multilib.db: gzip compressed data, last modified: Wed Apr 2 05:12:37 2014, from Unix ~~~~
Where and why would un-gzipping strike like this? And now I've confirmed that this un-gzipping doesn't happen on my
On Wed, Apr 02, 2014 at 10:16:04AM +0200, Magnus Therning wrote: private computer at home. So, what's causing this un-gzipping of the downloaded repo db, I wonder?
/M
There may be a transparent proxy in your routing chain that strips compression in order to run a virus scan. The server sends these headers for haskell-core.db ( curl -I http://xsounds.org/~haskell/core/x86_64/haskell-core.db ) Content-Type: application/x-tar Content-Encoding: x-gzip It might work as expected without a Content-Encoding header: Content-Type: application/x-gzip
There may be a transparent proxy in your routing chain that strips compression in order to run a virus scan.
Time for SSL-securing Arch Linux repos to prevent any sort of man-in-the-middle attacks? Even such trivial things like compression stripping, or image optimization often performed by mobile internet providers is a man-in-the-middle. This should be fought by any means. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
On 02/04/14 12:47 PM, Nowaker wrote:
There may be a transparent proxy in your routing chain that strips compression in order to run a virus scan.
Time for SSL-securing Arch Linux repos to prevent any sort of man-in-the-middle attacks? Even such trivial things like compression stripping, or image optimization often performed by mobile internet providers is a man-in-the-middle. This should be fought by any means.
Packages are already signed, and pacman has support for signing the repositories. Using TLS for repositories is close to useless because the mirrors are not *really* trusted entities, and the CA system is a broken alternative to the solid archlinux-keyring package.
On 02/04/14 01:00 PM, Daniel Micay wrote:
On 02/04/14 12:47 PM, Nowaker wrote:
There may be a transparent proxy in your routing chain that strips compression in order to run a virus scan.
Time for SSL-securing Arch Linux repos to prevent any sort of man-in-the-middle attacks? Even such trivial things like compression stripping, or image optimization often performed by mobile internet providers is a man-in-the-middle. This should be fought by any means.
Packages are already signed, and pacman has support for signing the repositories. Using TLS for repositories is close to useless because the mirrors are not *really* trusted entities, and the CA system is a broken alternative to the solid archlinux-keyring package.
We aren't actually signing the sync databases yet, but should be. Even if it means using a low-trust key on the servers, it would need to be treated differently than the package signing keys if it was a lower trust level though, because it shouldn't be able to sign packages.
Am 02.04.2014 19:01, schrieb Daniel Micay:
On 02/04/14 12:47 PM, Nowaker wrote:
There may be a transparent proxy in your routing chain that strips compression in order to run a virus scan. Time for SSL-securing Arch Linux repos to prevent any sort of man-in-the-middle attacks? Even such trivial things like compression stripping, or image optimization often performed by mobile internet providers is a man-in-the-middle. This should be fought by any means. Packages are already signed, and pacman has support for signing the repositories. Using TLS for repositories is close to useless because the mirrors are not *really* trusted entities, and the CA system is a broken alternative to the solid archlinux-keyring package. We aren't actually signing the sync databases yet, but should be. Even if it means using a low-trust key on the servers, it would need to be
On 02/04/14 01:00 PM, Daniel Micay wrote: treated differently than the package signing keys if it was a lower trust level though, because it shouldn't be able to sign packages.
Maybe require all certificates used for package signing to have the "codeSigning" capability? The database certificate won't have that flag.
On Wed, Apr 02, 2014 at 01:00:00PM -0400, Daniel Micay wrote:
On 02/04/14 12:47 PM, Nowaker wrote:
There may be a transparent proxy in your routing chain that strips compression in order to run a virus scan.
Time for SSL-securing Arch Linux repos to prevent any sort of man-in-the-middle attacks? Even such trivial things like compression stripping, or image optimization often performed by mobile internet providers is a man-in-the-middle. This should be fought by any means.
Packages are already signed, and pacman has support for signing the repositories. Using TLS for repositories is close to useless because the
Well, if there's something on the path from repo to client that re-writes downloads, then pacman's support for signing repos isn't worth very much when it comes to achieving my end goal. Sure, I'm alerted to the fact that the packages I receive are modified, but it doesn't help me updating my system. Something would be needed that throws a spanner in the works of the entity that modifies my downloads; SSL would do that. Maybe there are other ways of achieving the same goal.
mirrors are not *really* trusted entities, and the CA system is a broken alternative to the solid archlinux-keyring package.
The trust sits in the signing of repos, which means there is no need for trust in the transport layer in this particular scenario; in other words, it's irrelevant that mirrors are untrusted and it's equally irrelevant that the CA system is broken ;) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
On Wed, 02 Apr 2014 18:47:52 +0200 Nowaker <enwukaer@gmail.com> wrote:
There may be a transparent proxy in your routing chain that strips compression in order to run a virus scan.
Time for SSL-securing Arch Linux repos to prevent any sort of man-in-the-middle attacks? Even such trivial things like compression stripping, or image optimization often performed by mobile internet providers is a man-in-the-middle. This should be fought by any means.
If you are talking about mirrors, then look at https://www.archlinux.org/mirrorlist/all/https/ . At least in my experience, using tls allows to evade certain routers which redirect to a captive portal if plain http is used, but don't touch encrypted traffic (e.g. if you are in a hotel and need to install something). However, tls adds CPU overhead and is not a way to fight broken ISPs and proxies/routers. Cheers, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Wed, Apr 2, 2014 at 6:09 PM, ProgAndy <admin@progandy.de> wrote:
There may be a transparent proxy in your routing chain that strips compression in order to run a virus scan. The server sends these headers for haskell-core.db ( curl -I http://xsounds.org/~haskell/core/x86_64/haskell-core.db )
Content-Type: application/x-tar Content-Encoding: x-gzip
It might work as expected without a Content-Encoding header:
Content-Type: application/x-gzip
Yes, you are probably right. I just didn't think anyone would actually configure a proxy to deliver the un-gzipped result to the client. That sounds like a way to break all kinds of things! I'll ask around here to see if this is the case. I don't have direct control over the server where the repo is, but I might be able to convince the admins that it's a bad idea to put Content-Encoding into reponses. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On Thu, Apr 03, 2014 at 01:25:19PM +0200, Magnus Therning wrote:
On Wed, Apr 2, 2014 at 6:09 PM, ProgAndy <admin@progandy.de> wrote:
There may be a transparent proxy in your routing chain that strips compression in order to run a virus scan. The server sends these headers for haskell-core.db ( curl -I http://xsounds.org/~haskell/core/x86_64/haskell-core.db )
Content-Type: application/x-tar Content-Encoding: x-gzip
It might work as expected without a Content-Encoding header:
Content-Type: application/x-gzip
Yes, you are probably right. I just didn't think anyone would actually configure a proxy to deliver the un-gzipped result to the client. That sounds like a way to break all kinds of things!
I'll ask around here to see if this is the case.
I don't have direct control over the server where the repo is, but I might be able to convince the admins that it's a bad idea to put Content-Encoding into reponses.
Now after an upgrade of Apache by the administrator the Content-Encoding header is gone. Also I found out that there is a possibility to control mime types via .htaccess files. I put the following into one AddTypw application/octet-stream .gz and now the Content-Type is modified too. Hopefully that'll fix it, but I'll have to test when I get to work tomorrow. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Heuristic is an algorithm in a clown suit. It’s less predictable, it’s more fun, and it comes without a 30-day, money-back guarantee. -- Steve McConnell, Code Complete
participants (5)
-
Daniel Micay
-
Leonid Isaev
-
Magnus Therning
-
Nowaker
-
ProgAndy