Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update #99

wants to merge 1 commit into from


Copy link

@bartero bartero commented Aug 25, 2018

I have just learned, that the Lineage team has changed the way they sign the public builds.

I got to know why the keytool keep telling me: Not a signed jar file from this post.

Please update your wiki page! :-)

I have just learned, that the Lineage team has changed the way they sign the public builds.

I got to know why the **keytool** keep telling me: `Not a signed jar file` from this [post](

Please update your wiki page! :-)
Copy link

Also: the update_verifier uses an embedded public key, but I don't see any way to get a fingerprint of that key that is posted to a public site (as was done with the old method at

What is the advantage of the new approach? Using the signed jar file inspired a lot of confidence because it is such a well-known method, and easy to test using a tool (keytool) from outside the site of the code we're validating.

Copy link

I suggest dropping the old instructions completely. There is no use in carrying sold stuff. The new way seems to work for old archives, too. (t least for the archive I've tested.)

Anyway the new instructions have several issues:
a) the pip install command as shown tries to install system-wide, thus it needs to be run as root (or --user needs to be passed
b) this will pollute the system's respective the user's environment, which might not be desired
c) on Windows pip might not be on the path (see this talk)

Preferable and recommended way is to use a virtual environment:

git clone
cd update_verifier
python3 -m venv .
bin/pip install -r requirements.txt
bin/python lineageos_pubkey /path/to/zip

Copy link

@brad2014 I described the way to re-establish the chain of trust after the way to verify public builds has changed here:

Copy link

bartero commented Aug 31, 2018

@htgoebel Thank you for your effort!
I will look at it later today

Copy link

xaverdh commented Oct 14, 2018

On a side note, why aren't the builds just signed with gpg (e.g. with a detached signature) ?
Maybe thats because I am from the "desktop linux" world, but that looks like the standard procedure to me.

Copy link

htgoebel commented Aug 7, 2019

@ItzLevvie forcefully requires to have a google account - which excludes me from contributing.

@haggertk haggertk closed this Nov 1, 2019
Copy link

htgoebel commented Nov 2, 2019

@haggertk Has this been solved, or why has this been closed?

Closing issue without stating why is not a honest style and able to discourage contributors.

Copy link

htgoebel commented Nov 3, 2019

@ItzLevvie Many thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
6 participants