546835 - 'apt-get update' for Mozilla Catalog cannot be verified on Nokia N900

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[Venomrush]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: 

Perform apt-get update on Mozilla Catalog always produce errors.

Reproducible: Always

Steps to Reproduce:
1. Open Terminal on Nokia N900
2. Ensure Mozilla Catalog (http://moff.mozilla.com/maemo/multi) is enabled.
3. Run as root the following: apt-get update
Actual Results:  
Mozilla Catalog returns:

W: GPG error: http://moff.mozilla.com chinook Release: The following signatures couldn't be verified because the public key is not available. NO_PUBKEY 667387BFFF445C24
W: You may want to run apt-get update to correct these problems

Expected Results:  
Update via apt-get should not produce any errors when updating Mozilla Catalog

Comment 1

[Aki Sasaki (not active)]

Hey there.
The public key is available here:

  http://ftp.mozilla.org/pub/mozilla.org/mobile/mozilla-maemo-gpg-public-key

If you download that, you can

  sudo apt-key add mozilla-maemo-gpg-public-key

which should fix this.

Comment 2

[Venomrush]

I'm abit of a newbie here.

1. Where exactly do I download this to on the N900? Root? 
2. How should I save it as? mozilla-maemo-gpg-public-key.key?

Many thanks

Comment 3

[Venomrush]

Ok I figured it out.

Save it just as 'mozilla' into /home/user/.ssh
Then I did: apt-key add /home/user/.ssh/mozilla 

I got a return message as OK

I then performed apt-get update again but this time introduces new error, the exact error message is:

W: Conflicting distribution: http://moff.mozilla.com chinook Release (expected chinook but got )
W: Failed to fetched http://moff.mozilla.com/maemo/multi/dists/chinook/Release Unable to find expected entry  release/binary-armel/Packages in Meta-index file (malformed Release file?)

E: Some index files fialed to download, they have been ignored, or old ones used instead.


As doing apt-get update for Mozilla Catalog still produces error, hence I am reopening this bug.

Comment 4

[Aki Sasaki (not active)]

Hm, I'm also seeing this.
After some digging, I found https://lists.ubuntu.com/archives/ubuntu-devel/2007-August/024174.html

Is anyone able to install from mozilla.com/m ?

Comment 5

[Aki Sasaki (not active)]

Aha -- luckily the Release check only triggers if you apt-key add.
So adding the key breaks our current catalog.

I guess the workaround for now is

  apt-key del "Mozilla Release Engineering <[e-mail]>"

which triggers the original bug; we do need to fix this but this shouldn't be affecting the general public.

Comment 6

[Aki Sasaki (not active)]

Attachment: Fix apt-ftparchive command

As mentioned in comment 4, writing the output of apt-ftparchive to a file inside the directory tree is problematic because we then get a false checksum inside the file.

The workaround is to write the output to a temp file, then copy that file into the directory.

Also, I wrote some stuff in to be able to keep a history of old debs in the repo (rsync, optionally clobber just this section).  Turns out we don't particularly care about old debs in the repo; we only want to serve the latest and historical debs are available on ftp.  So I'm just nuking dists/ and populating an empty repository now.

Comment 7

[Aki Sasaki (not active)]

Oh -- ran this, downloaded fennec from the repo, then tried apt-get update with and without the key and didn't get any errors.

Comment 8

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 432047 [details] [diff] [review]
Fix apt-ftparchive command

>diff --git a/release/signing/signdebs.mk b/release/signing/signdebs.mk
>-clean-install-file:
>-	rm -f $(WORKDIR)/$(INSTALL_FILENAME)

r+, assuming something else does this for you, eg starting from an empty WORKDIR or adding it to the setup: target

Comment 9

[Aki Sasaki (not active)]

Comment on attachment 432047 [details] [diff] [review]
Fix apt-ftparchive command

(In reply to comment #8)
> (From update of attachment 432047 [details] [diff] [review])
> >diff --git a/release/signing/signdebs.mk b/release/signing/signdebs.mk
> >-clean-install-file:
> >-	rm -f $(WORKDIR)/$(INSTALL_FILENAME)
> 
> r+, assuming something else does this for you, eg starting from an empty
> WORKDIR or adding it to the setup: target

Yup, the rm -rf in the setup: target.

Checked in:
http://hg.mozilla.org/build/tools/rev/0c8546fc9b83

Comment 10

[Aki Sasaki (not active)]

Venomrush:  This should be fixed during our next release; you shouldn't have to wait too long.

Comment 11

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #9)
> Yup, the rm -rf in the setup: target.

Looks like that's removing $(WORKDIR)/dists and will miss $(WORKDIR)/$(INSTALL_FILENAME).

Comment 12

[Aki Sasaki (not active)]

Attachment: add $(INSTALL_FILEPATH) to rm -rf

If it's a matter of me overlooking a small crucial detail, or you overlooking a small crucial detail, I shoulda known where the smart money goes.

Attaching two possible fixes... feel free to choose whichever seems cleaner. This one adds $(INSTALL_FILEPATH) to the rm -rf in setup.

Comment 13

[Aki Sasaki (not active)]

Attachment: alternate fix: re-add clean-install-file target

Comment 14

[Aki Sasaki (not active)]

Comment on attachment 432879 [details] [diff] [review]
add $(INSTALL_FILEPATH) to rm -rf

http://hg.mozilla.org/build/tools/rev/029103f576bb

Comment 15

[Aki Sasaki (not active)]

Reopening; I'm seeing this in nightlies that should already have this fix.

Comment 16

[Aki Sasaki (not active)]

Hm, I've tried Packages.gz -> Packages and having both, but that only changed error messages.

I'm going to try using http://repository.maemo.org/extras/dists/chinook/ as a model.

Comment 17

[Aki Sasaki (not active)]

It's looking like the maemo repos above don't use Release.gpg.
When I remove the Release.gpg it clears up the apt-get update errors for me.

Should we skip the gpg signing?

Comment 18

[Aki Sasaki (not active)]

(In reply to comment #17)
> It's looking like the maemo repos above don't use Release.gpg.
> When I remove the Release.gpg it clears up the apt-get update errors for me.
> 
> Should we skip the gpg signing?

Stuart: is there someone from Nokia who can provide some insight into this?

Comment 19

[Aki Sasaki (not active)]

Stuart, afaict this is the remaining blocker for 1.0.1.

Not sure if you want to make a call here, wait til you hear back, or remove this from the blocker list.

Over to you; let me know what you want to do.

Comment 20

[Stuart Parmenter]

This shouldn't block 1.0.1, since we have the same problem with 1.0 -- working on resolving though

Comment 22

[Sergey Yanovich]

(In reply to comment #16)
> I'm going to try using http://repository.maemo.org/extras/dists/chinook/ as a
> model.

Maemo repository [1] contains Release.gpg file as of today. Maybe you can recheck your fix?

http://repository.maemo.org/extras/dists/fremantle-1.2/Release

Comment 23

[acabre]

Adding the GPG key at http://ftp.mozilla.org/pub/mozilla.org/mobile/mozilla-maemo-gpg-public-key still triggers this bug on PR1.3.

With the key added
-------
W: Conflicting distribution: http://moff.mozilla.com fremantle Release (expected fremantle but got )
W: Failed to fetch http://moff.mozilla.com/latest-beta/maemo/multi/dists/fremantle/Release  Unable to find expected entry  release/binary-armel/Packages in Meta-index file (malformed Release file?)

E: Some index files failed to download, they have been ignored, or old ones used instead.

Without the key added:
-------
W: GPG error: http://moff.mozilla.com fremantle Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 667387BFFF445C24

Comment 24

[Adam Bolte]

Confirming what acabre said. I actually removed fennec weeks (>month?) ago, thinking I'll do a manual purge of fennec and the repos, and wasn't able to reinstall rennec since! Kept getting horrible errors when I re-added the Mozilla repo.

All this time, I figured a huge problem like this would be fixed in hours so didn't bother looking into it. Well it finally drove me crazy enough to investigate, so found this bug report and removed the key.

Hate the workaround - very insecure. I prey your repos don't get cracked since mobile devices won't be able to verify what they are installing is considered trustworthy.

Comment 25

[domlyons]

This problem still exists for Fennec 4 final.

It was really hard to find the workaround (no, for me it's no real solution!).

Comment 26

[Aki Sasaki (not active)]

Maemo is now tier3, and we're no longer shipping/building it.
I recommend a RESO INCOMPLETE.

Comment 27

[Narcis Garcia]

Aki, can you explain the «tier3» expression, please?

Comment 28

[Aki Sasaki (not active)]

https://developer.mozilla.org/en/Supported_build_configurations

"Tier-3 platforms have a maintainer or community which attempt to keep the platform working. These platforms may or may not work at any time, and often have little test coverage"

Effectively, it means that Mozilla Corporation is not supporting Maemo, but will accept patches from people who do want to support it.

Comment 29

[Aki Sasaki (not active)]

Per comment 26.