Why is this an an unencrypted repo?Method 2:
1. Download antix-archive-keyring_20019.3.13_all.deb from here: http://repo.antixlinux.com
In the directory where you downloaded the deb, use gdebi to install
EXPKEYSIG error and fix
Re: EXPKEYSIG error and fix
- anticapitalista
- Developer
- Posts: 4160
- Joined: Sat Jul 15, 2006 10:40 am
Re: EXPKEYSIG error and fix
So you can download that deb
anticapitalista
Reg. linux user #395339.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - lean and mean.
https://antixlinux.com
Reg. linux user #395339.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - lean and mean.
https://antixlinux.com
Re: EXPKEYSIG error and fix
I just installed MX on main PC and got this error. oops's one liner fixed the problem. Thanks.
“We must be free not because we claim freedom, but because we practice it.”
—William Faulkner
—William Faulkner
Re: EXPKEYSIG error and fix
I think an announcement and the new apt-get instructions should be posted on the announcement section of the forum because I understand the expiry of key is now also affecting the mx15/16 version of said Repo.
Desktop: Intel i5-4460, 16GB RAM, Intel integrated graphics
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400
Re: EXPKEYSIG error and fix
If someone would compose the solution and post a blog on the website or here in MX News and Announcements I will add it. The subsequent posts and PM's seemingly giving different solutions have confused me. (change the repo, wait for the package to show in updates)
Forum Rules
Guide - How to Ask for Help
richb Administrator
System: MX 23 KDE
AMD A8 7600 FM2+ CPU R7 Graphics, 16 GIG Mem. Three Samsung EVO SSD's 250 GB
Guide - How to Ask for Help
richb Administrator
System: MX 23 KDE
AMD A8 7600 FM2+ CPU R7 Graphics, 16 GIG Mem. Three Samsung EVO SSD's 250 GB
Re: EXPKEYSIG error and fix
@all:
My general question would be whether there would be some safer way of handling situations like that (from a user perspective) – safer than downloading new keys via the open internet.
I remember that there were similar situations with MX-16 or MX-17, and similar advice was given then.
Unfortunately, I'm no expert at all when it comes to this key/signature stuff, but my naïve assumption would be that downloading authentication-related stuff via the open internet would be a no-go, as it breaks the signature/authentication chain of your protected Linux ecosystem.
To me, downloading keyrings via the open internet sounds like an invitation to MIT-attackers (https://en.wikipedia.org/wiki/Man-in-the-middle_attack), who might in this way build bridgeheads that would allow them to compromise other your system.
Please correct me if I'm wrong. As said, I'm not an expert, and I've never really understood the details of apt's handling of keyrings and signatures.
Greetings, and a great week to all of you, Joe
My general question would be whether there would be some safer way of handling situations like that (from a user perspective) – safer than downloading new keys via the open internet.
I remember that there were similar situations with MX-16 or MX-17, and similar advice was given then.
Unfortunately, I'm no expert at all when it comes to this key/signature stuff, but my naïve assumption would be that downloading authentication-related stuff via the open internet would be a no-go, as it breaks the signature/authentication chain of your protected Linux ecosystem.
To me, downloading keyrings via the open internet sounds like an invitation to MIT-attackers (https://en.wikipedia.org/wiki/Man-in-the-middle_attack), who might in this way build bridgeheads that would allow them to compromise other your system.
Please correct me if I'm wrong. As said, I'm not an expert, and I've never really understood the details of apt's handling of keyrings and signatures.
Greetings, and a great week to all of you, Joe
- dolphin_oracle
- Developer
- Posts: 19929
- Joined: Sun Dec 16, 2007 1:17 pm
Re: EXPKEYSIG error and fix
I may be off base but...MX-16_fan wrote: ↑Sun Mar 17, 2019 3:38 pm @all:
My general question would be whether there would be some safer way of handling situations like that (from a user perspective) – safer than downloading new keys via the open internet.
I remember that there were similar situations with MX-16 or MX-17, and similar advice was given then.
Unfortunately, I'm no expert at all when it comes to this key/signature stuff, but my naïve assumption would be that downloading authentication-related stuff via the open internet would be a no-go, as it breaks the signature/authentication chain of your protected Linux ecosystem.
To me, downloading keyrings via the open internet sounds like an invitation to MIT-attackers (https://en.wikipedia.org/wiki/Man-in-the-middle_attack), who might in this way build bridgeheads that would allow them to compromise other your system.
Please correct me if I'm wrong. As said, I'm not an expert, and I've never really understood the details of apt's handling of keyrings and signatures.
Greetings, and a great week to all of you, Joe
my understanding of this is that the issue isn't that the repos are encrypted (they aren't), but that they are signed. In order to verify the private signature of the signer of the repo packages, the end user needs the public key, which is what the archive package provides. So actually, its designed to work this way, a public key that is distributed and a private key that is secret. downloading the key from our own server via a link we provide, and having the key work against our own repos should be a strong indication that things are as they should be.
anyone that has ever added a key manually with "apt-key add -" faces a similar issue. I guess if you don't trust the public/private key relationship, you would have to assume that every mirror and every repository and release file was compromised. Since we the operators are saying that nothing was compromised, and the fact that the repo operators are pretty sharp people, I think we are safe in assuming that the keys are good.
the safer and less troublesome method is to update the key archive ahead of time. this one got missed this time. it happens, we are all human.
http://www.youtube.com/runwiththedolphin
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.
lenovo ThinkPad X1 Extreme Gen 4 - MX-23
FYI: mx "test" repo is not the same thing as debian testing repo.
Re: EXPKEYSIG error and fix
That's actually a good question.
And yes, it is save and secure, even downloading a public-key through the un-encrypted internet is not the issue.
Because, the here shown key-finger print is the key-element to verify the downloaded public-key of the signing key is legitimate.
The user can/should verify the key by it's fingerprint:
One method I have shown above:
Code: Select all
gpg --with-fingerprint --no-default-keyring --keyring /etc/apt/trusted.gpg.d/antix-archive-keyring.gpg --list-keys
/etc/apt/trusted.gpg.d/antix-archive-keyring.gpg
------------------------------------------------
pub rsa2048 2013-03-13 [SC] [expires: 2021-05-01]
ED57 48AC 0E57 5DD2 49A5 6B84 DB36 CDF3 452F 0C20
uid [ unknown] antiX (antix repo) <repo@antixlinux.com>
sub rsa2048 2013-03-13 [E] [expires: 2021-05-01]
is unique and after manually verification save and secure to use and to trust.
First of all, such situation shall not happen, and the issue was fixed 1 day later by providing an additional package through the normal secure update mechanism.
So the question is good, but if carefully proceeded even such unusual situation can be solved fairly securely.
HTH
Gigabyte Z77M-D3H, Intel Xeon E3-1240 V2 (Quad core), 32GB RAM,
GeForce GTX 770, Samsung SSD 850 EVO 500GB, Seagate Barracuda 4TB
GeForce GTX 770, Samsung SSD 850 EVO 500GB, Seagate Barracuda 4TB
Re: EXPKEYSIG error and fix
@dolphin_oracle:
Thanks for this explanation. Greetings, and have a good week, Joe
dolphin_oracle wrote: ↑Sun Mar 17, 2019 7:11 pm (...)
I may be off base but...
my understanding of this is that the issue isn't that the repos are encrypted (they aren't), but that they are signed. In order to verify the private signature of the signer of the repo packages, the end user needs the public key, which is what the archive package provides. So actually, its designed to work this way, a public key that is distributed and a private key that is secret. downloading the key from our own server via a link we provide, and having the key work against our own repos should be a strong indication that things are as they should be.
anyone that has ever added a key manually with "apt-key add -" faces a similar issue. I guess if you don't trust the public/private key relationship, you would have to assume that every mirror and every repository and release file was compromised. Since we the operators are saying that nothing was compromised, and the fact that the repo operators are pretty sharp people, I think we are safe in assuming that the keys are good.
the safer and less troublesome method is to update the key archive ahead of time. this one got missed this time. it happens, we are all human.
Thanks for this explanation. Greetings, and have a good week, Joe
Re: EXPKEYSIG error and fix
@fehlix:
Thanks for the explanation. Appears to me that this might be a valuable piece of information for the FAQ / Wiki / User Manual as well. Greetings, and have a nice week, Joe
fehlix wrote: ↑Sun Mar 17, 2019 8:09 pmThat's actually a good question.
And yes, it is save and secure, even downloading a public-key through the un-encrypted internet is not the issue.
Because, the here shown key-finger print is the key-element to verify the downloaded public-key of the signing key is legitimate.
The user can/should verify the key by it's fingerprint:
One method I have shown above:And the shown key-fingerprint "ED57 48AC 0E57 5DD2 49A5 6B84 DB36 CDF3 452F 0C20"Code: Select all
gpg --with-fingerprint --no-default-keyring --keyring /etc/apt/trusted.gpg.d/antix-archive-keyring.gpg --list-keys /etc/apt/trusted.gpg.d/antix-archive-keyring.gpg ------------------------------------------------ pub rsa2048 2013-03-13 [SC] [expires: 2021-05-01] ED57 48AC 0E57 5DD2 49A5 6B84 DB36 CDF3 452F 0C20 uid [ unknown] antiX (antix repo) <repo@antixlinux.com> sub rsa2048 2013-03-13 [E] [expires: 2021-05-01]
is unique and after manually verification save and secure to use and to trust.
First of all, such situation shall not happen, and the issue was fixed 1 day later by providing an additional package through the normal secure update mechanism.
So the question is good, but if carefully proceeded even such unusual situation can be solved fairly securely.
HTH
Thanks for the explanation. Appears to me that this might be a valuable piece of information for the FAQ / Wiki / User Manual as well. Greetings, and have a nice week, Joe