[arch-general] usbguard package neglected
Hello,
the package usbguard was flagged out of date in november. Three new versions came out since then. A package update or any info on this would be greatly appreciated.
Kind regards
On 6/24/20 11:37 PM, arch user via arch-general wrote:
Hello,
the package usbguard was flagged out of date in november. Three new versions came out since then. A package update or any info on this would be greatly appreciated.
Kind regards
The trust chain is broken as the signing key changed and after multiple back and forth I still did not get a signed confirmation of the old key regarding the new maintainers and keys.
I will try to re ping them with w 5th mail, lets see if we have more luck now.
cheers, Levente
On 25.06.20 00:37, Levente Polyak via arch-general wrote:
The trust chain is broken as the signing key changed and after multiple back and forth I still did not get a signed confirmation of the old key regarding the new maintainers and keys.
I will try to re ping them with w 5th mail, lets see if we have more luck now.
Thanks for your reply and the information.
Sorry for the late answer but I had a second thought about it recently and have found several reasons why to update USBGuard anyway:
1) It is open source. If there are trust issues one can look at the source code and check what has changed between versions.
2) Developers of other packages don't ever sign their commits so they don't have a chain of trust at all. While a broken chain of trust might be a step backwards, it is still equivalent to having none.
3) Other Linux distributions have updated the package as well. This might seem like a weak reason but if I think about it, I find that it resembles some kind of peer review.
Just wanted to share those thoughts so you might have a second look at it.
Kind regards
On 10/26/20 10:36 AM, arch user via arch-general wrote:
Sorry for the late answer but I had a second thought about it recently and have found several reasons why to update USBGuard anyway:
- It is open source. If there are trust issues one can look at the
source code and check what has changed between versions.
Doing a security audit is expensive and time consuming. Not doing a security audit means "look at the source code and see what changed" accomplishes nothing whatsoever -- we know there are changes or there would not be a new version, but can you prove there are no hidden back doors?
- Developers of other packages don't ever sign their commits so they
don't have a chain of trust at all. While a broken chain of trust might be a step backwards, it is still equivalent to having none.
Absolutely not at all.
Projects that never signed their software are like people who live in a neighborhood where no one locks their front door, because it's too much work to fiddle with a door key.
Projects with a a broken chain of trust are like that one person who *does* lock his front door, but one day the lock got ripped off the door and replaced by a gaping hole. It is hugely suspicious and everyone walking down the street has good reason to notice and suspect a robbery occurred.
Now, it's *possible* the owner lost his key and destroyed his own front door in order to get back into his own house. But is it likely?
You could ask him, but he's a recluse slash internet person, so you're not really sure what he looks like. The guy wandering around inside the house might be the owner, but he might also be a thief... what do you do?
- Other Linux distributions have updated the package as well. This
might seem like a weak reason but if I think about it, I find that it resembles some kind of peer review.
... apparently you say "oh, I guess you're the owner then, sorry to bother you. BTW you should probably fix your door because it looks weird now. No pressure."
That's indeed weak. What kind of peer review are you claiming this is, exactly?
...
The point of a signing key is to say "this key certifies the correct software and I commit to using it. Anything else is automatically suspect as malware".
You don't immediately respond by saying "well it came from the same website and some unverified source told me the key totally got lost but it's fine. So let's blindly click accept".
It doesn't matter if other distros are okay with that. Arch Linux is not.
On 27.10.20 03:45, Eli Schwartz via arch-general wrote:
The point of a signing key is to say "this key certifies the correct software and I commit to using it. Anything else is automatically suspect as malware".
You don't immediately respond by saying "well it came from the same website and some unverified source told me the key totally got lost but it's fine. So let's blindly click accept".
The only thing a signing key accomplishes is that you can verify what other commits were made by that signing key, i. e. person. If you verified the key via a second channel you also know the person the key belongs to. Anything beyond that is just a point of view.
A signing key has nothing to do with malware at all. What made you think the software hasn't been malware in the first place? What makes you think the person owning that signing key isn't writing good software until some distros are trusting his key, adding the software as official package and then the person starts implementing evil backdoors?
I'm just wondering, because you can easily write malicious software and sign it with the same key all the time.
You can build the latest yourself https://aur.archlinux.org/packages/usbguard-git/ but it is good that Levente is being diligent in verifying the new maintainers.
On Tue, Oct 27, 2020 at 4:31 AM arch user via arch-general < arch-general@archlinux.org> wrote:
On 27.10.20 03:45, Eli Schwartz via arch-general wrote:
The point of a signing key is to say "this key certifies the correct software and I commit to using it. Anything else is automatically suspect as malware".
You don't immediately respond by saying "well it came from the same website and some unverified source told me the key totally got lost but it's fine. So let's blindly click accept".
The only thing a signing key accomplishes is that you can verify what other commits were made by that signing key, i. e. person. If you verified the key via a second channel you also know the person the key belongs to. Anything beyond that is just a point of view.
A signing key has nothing to do with malware at all. What made you think the software hasn't been malware in the first place? What makes you think the person owning that signing key isn't writing good software until some distros are trusting his key, adding the software as official package and then the person starts implementing evil backdoors?
I'm just wondering, because you can easily write malicious software and sign it with the same key all the time.
participants (5)
-
arch user
-
Eli Schwartz
-
Justin Capella
-
Levente Polyak
-
p5l3jutd3ln5gsy0＠mailban.de