Am 02.04.2014 17:56, schrieb Magnus Therning:

...

On Wed, Apr 2, 2014 at 9:32 AM, Magnus Therning 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) " 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) " 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

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.

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, 02 Apr 2014 18:47:52 +0200 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.

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 Thu, Apr 03, 2014 at 01:25:19PM +0200, Magnus Therning wrote:

On Wed, Apr 2, 2014 at 6:09 PM, ProgAndy 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