Issues with updating
- Thread starter Magic Sam
- Start date
Phlyra
FLOSSing
- Joined
- Jul 25, 2019
- Messages
- 1,517
Is that anything like what’s reported here (though obviously you’re talking about an OS image rather than a firmware image) : https://forums.puri.sm/t/pureboot-image-changes-after-first-boot/15405
levi
Still fresh, damnit!
No not really. The user there is reporting a region of flash memory changes after first boot (presumably an unused area of flash memory, if it doesn't touch any files). Logen here is reporting that when you do an OS update (via apt update I assume) it fails due to signature errors and aborts any changes, I'd have thought. As far as I can tell Logen isn't even checking the shasum of his whole OS drive, so can't say whether the same thing is happening to him, but the prime problem is that the linked user gets changes when then don't want them, while logen does want changes but the system won't give them to him.
Magic Sam
Forever Homebrew
Hi all 
@logen : I get the following when trying to update
Cheers, Magic Sam
@logen : I get the following when trying to update
Code:
Err:7 https://packages.pyra-handheld.com unstable/ InRelease
The following signatures were invalid: EXPKEYSIG B9CB5B9FA32E2FAE Pyra Dev <pyra-dev@pyra-handheld.com>
Fetched 786 kB in 7s (110 kB/s)
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.pyra-handheld.com unstable/ InRelease: The following signatures were invalid: EXPKEYSIG B9CB5B9FA32E2FAE Pyra Dev <pyra-dev@pyra-handheld.com>
W: Failed to fetch http://packages.pyra-handheld.com/unstable/InRelease The following signatures were invalid: EXPKEYSIG B9CB5B9FA32E2FAE Pyra Dev <pyra-dev@pyra-handheld.com>
W: Some index files failed to download. They have been ignored, or old ones used instead.Cheers, Magic Sam
levi
Still fresh, damnit!
I've downloaded the archive key from that site as ran it through gpg: the result is:
That's probably the problem.
Code:
pub rsa3072 2019-11-13 [SC] [expired: 2021-11-12]
DAAA8C08C72225DAB72FCA0AB9CB5B9FA32E2FAE
uid Pyra Dev <pyra-dev@pyra-handheld.com>
sub rsa3072 2019-11-13 [E] [expired: 2021-11-12]That's probably the problem.
aTc
Very Active Member
- Joined
- Apr 25, 2009
- Messages
- 253
Yes,
I thought that key was set to never expire, but it seems it wasn't.
Unfortunately there's no way to fix it from the server side.
To fix it do:
After that, apt update/upgrade should work without complaints again.
I thought that key was set to never expire, but it seems it wasn't.
Unfortunately there's no way to fix it from the server side.
To fix it do:
Code:
wget https://packages.pyra-handheld.com/pyra-public.pgp
sudo apt-key add pyra-public.pgpAfter that, apt update/upgrade should work without complaints again.
levi
Still fresh, damnit!
Wouldn't it be better to regenerate a key, build as many packages you are able to in a few days and upload that all to the server? I guess if you can't set an unexpiring key you're meant to periodically put a new key there and sign new packages with that key? Actually I'm not sure you need to sign packages with this key, other linuxes generally don't sign the repo but sign each package instead, so maybe debian does it the other way round, rather than signing both.
levi
Still fresh, damnit!
Okay, so the difficulty in that is presumably people's distributions contain the private key to check against that repo. Perhaps that's what you've done and the instruction above are a hack to provide the keys you need right now rather than providing them by the normal method which presumably is in some package or other.
aTc
Very Active Member
- Joined
- Apr 25, 2009
- Messages
- 253
No, the distro contains the public key, the repo signs with the private key, it wouldn't be very secure otherwise
The "hack" above is because you can't get the new public keys through the normal method of the pyra-archive-keyring package, because you can't get new packages from the repo.
The "hack" above is because you can't get the new public keys through the normal method of the pyra-archive-keyring package, because you can't get new packages from the repo.
levi
Still fresh, damnit!
Okay, I was misled by gpg reporting the archive.key file contained a public key (and a sub key), but other than that sounds like we're on the same page.
To requote your instructions to leave them near the end for anyone reading this thread looking for answers:
To requote your instructions to leave them near the end for anyone reading this thread looking for answers:
Code:
wget https://packages.pyra-handheld.com/pyra-public.pgp
sudo apt-key add pyra-public.pgp
Maybe a Pro Tipp: Copy and Past should work for these Terminal Commands ^^
Well, @levi and @aTc are both right, but as a general rule, copying and pasting commands involving apt-key without thinking what they do is not the best advice. Even if the command was right, thinking about it or asking is wise.
Debian repositories are signed and tools like apt-get etc (or the software it uses) do check signatures. That's in addition of any signature in the package itself. There are signed files with lists of the hashes of other files.
Nowadays everything is https and cdns, but back then there were a lot of http and ftp mirrors, and it was easier to set up one if you just had to copy file trees to an unsecure server and have the tooling provide the security. This also means that the distro
didn't have to trust the mirror admins (or just trust them being nice on the load to other mirrors when syncing), and since it was all free software, anyone could put up a mirror anyway, with or without vetting by the distro, so it was better to have the distro private keys in one place and the repository widely distributed. A release must verifiably specify which packages and versions it contains, otherwise a mirror could sneak in some older version with an exploitable vulnerability or something, which could still have a proper (old) package signature.
Also in debian FTP masters have quite authority in what packages and versions belong to the distro. It's not enough that a developer signs a package to have it automatically in the repo, because the idea is that the distribution works as an integrated whole.
A package might be perfectly fine on its own but not work well with some other or do things in a different way than the distro policy, so it makes sense that there's per package QA and distro wide QA, so that having package signatures and repo signatures
does not seem odd. I no longer know whether all packages are individually signed nowadays. But the distro is.
Debian repositories are signed and tools like apt-get etc (or the software it uses) do check signatures. That's in addition of any signature in the package itself. There are signed files with lists of the hashes of other files.
Nowadays everything is https and cdns, but back then there were a lot of http and ftp mirrors, and it was easier to set up one if you just had to copy file trees to an unsecure server and have the tooling provide the security. This also means that the distro
didn't have to trust the mirror admins (or just trust them being nice on the load to other mirrors when syncing), and since it was all free software, anyone could put up a mirror anyway, with or without vetting by the distro, so it was better to have the distro private keys in one place and the repository widely distributed. A release must verifiably specify which packages and versions it contains, otherwise a mirror could sneak in some older version with an exploitable vulnerability or something, which could still have a proper (old) package signature.
Also in debian FTP masters have quite authority in what packages and versions belong to the distro. It's not enough that a developer signs a package to have it automatically in the repo, because the idea is that the distribution works as an integrated whole.
A package might be perfectly fine on its own but not work well with some other or do things in a different way than the distro policy, so it makes sense that there's per package QA and distro wide QA, so that having package signatures and repo signatures
does not seem odd. I no longer know whether all packages are individually signed nowadays. But the distro is.
Ok so i will type the command by hand whit the awesome illuminated Pyra Keyboard ^^
The Problem is that i dont know what it makes so i wouldnd understand that much what i would type..
I know that the Pyra should travel to the URL in the Command and Download a pyra-puplic.pgp file ^^
The Problem is that i dont know what it makes so i wouldnd understand that much what i would type..
I know that the Pyra should travel to the URL in the Command and Download a pyra-puplic.pgp file ^^
No, no. Of course it doesn't matter whether one types it manually or copies and pastes it. Just think what it does before pressing enter.
Yes, the first command downloads the repo public key from the https site "packages.pyra-handheld.com" to your current working directory and the second one installs it as a trusted key for your Pyra to accept upgrades signed with the corresponding private key.
Seems like i may not be the best to chose as Pyra Owner Number 28 ^^
Allthough i learned a lot in the 10 Years im allready here...
EDIT: Just made the Update in my work free time, worked quite good, and it asked for the "Autoremove" Command because there where now some Packages that arent usefull anymore, so i dit this also, i hope this wasnt a bad decission..
Allthough i learned a lot in the 10 Years im allready here...
EDIT: Just made the Update in my work free time, worked quite good, and it asked for the "Autoremove" Command because there where now some Packages that arent usefull anymore, so i dit this also, i hope this wasnt a bad decission..
Last edited:
levi
Still fresh, damnit!
I tend to think copy&paste is safer than typing in by hand, although it's always possible to screw both up. I recommend copy and paste but not including the newline and manually checking it by eye before hitting enter.
I for one am very glad that you're number 28, @matzesu
That's the point
I guess so, but I don't know either. I'm not that current with the repo contents.
levi
Still fresh, damnit!
If you mean to update asked to remove a handful of packages, I generally find this to be quite safe.
