Hi guys.
I've been pointed to the "low-hanging fruit" discussion on this list by a couple of people. I wasn't on this list, but now am.
So what is PackageKit:
• A daemon that accepts asynchronous jobs. • A way of letting certain groups of people do stuff to the package database with a fine grained server-client security model. • A system service that starts only when needed. • A way of inhibiting suspend/hibernate/restart/shutdown when performing actions. • An interface to a packaging backend.
The fine grained security model allows an installer application to be loaded as the user (without a root password), to do searches without a password, and to only ask the user for authentication for any privileged task, for instance updating the system or installing a package. This lets the admin decide what level of security is best for the box in question. [http://people.freedesktop.org/~hughsient/temp/pk-polkit.png]
A packaging backend can be something in a thread like libapt-pkg (as it has a C++ binding) or using a polling backend with external helper scripts for stuff like yum (python) or urpmi (perl) with no C bindings.
The helper scripts communicate over stdin, stderr and stdout using a loosly defined (by the backend) protocol, in an effort to make scripted synchronous operations into async ones with a common DBUS interface. I've started to define this here: [http://gitweb.freedesktop.org/?p=users/hughsient/PackageKit.git;a=blob_plain...]
What is Packagekit-gnome:
• An lightweight update applet that runs once per logged in user that refreshes the cache at startup and displays update status and critical security warnings. [http://people.freedesktop.org/~hughsient/temp/pk-updates-warning.png] • A way of seeing what other users are doing with PackageKit, so you can see why the hdd light is flashing after doing a fast user switch somewhere else. • An application installer. Note, gnome-app-install is probably going to be the long term target as this will be ported to the PackageKit API. [http://people.freedesktop.org/~hughsient/temp/pk-application2.png]
So, misconceptions in the thread so far (in my opinion):
Pirut and PackageKit are mutually exclusive: You can happily run them both side by side. I am now. If pirut is open then PK should queue the request until pirut is closed.
PackageKit is vapourware: Nope, I'm running it right now. True, only the dummy backend is supported but the apt and yum backends are coming on. The deps are also pretty harsh; you need PolicyKit, dbus-glib, dbus and PolicyKit-gnome all from git. F8 rpm's for PackageKit are in my repo [http://people.freedesktop.org/~hughsient/fedora/].
PackageKit API is rubbish: I know. It's unstable right now, and is changing to fulfill all the use-cases. My view is you have to let an API evolve to be optimal, rather than over-engineer everything when the complexities are not known. [http://people.freedesktop.org/~hughsient/temp/pk-interface.xml]
Error enums will not be powerful enough Fair enough, I hear you loud and clear. Maybe we can set a hint to the backend about the locale, but I would have to think about this more.
PackageKit will be included in F9/F10/desktop-spin/crackpot-spin That's up to you guys. I think it will be some time before the API is stable, and all the UI and policy bits and bobs are worked out. PackageKit also needs a security code review as sometimes it's running as the root user. So, the short story is I'm not pushing this to be included in fedora right now, as it can only do 10% of what the current tools can do.
PackageKit allows you to install stuff without a password Well, it allows the admin to set what sort of authentication you need to do each action, be it your own password, an admins password, or just to deny the request.
PackageKit is yet another system daemon to be started at boot time: Nope, it's started only when needed using system activation, and quits a few seconds after finishing it's last queued task.
We are just a layer over yum -y --ask-no-questions: If PackageKit is just a layer, I think the layer allows us to do some important things the old system could not, and allows us to share code between distros and desktop projects. Also, my view is that questions should never be asked. Who has ever clicked no to "Load GPG key from Fedora Project"? Is there a legal requirement to show such a warning?
So, I hope that has cleared things up a bit. Comments and suggestions welcome.
Thanks,
Richard Hughes.
On Wed, 22 Aug 2007 17:46:47 +0100 "Richard Hughes" hughsient@gmail.com wrote:
Also, my view is that questions should never be asked. Who has ever clicked no to "Load GPG key from Fedora Project"? Is there a legal requirement to show such a warning?
So, I hope that has cleared things up a bit. Comments and suggestions welcome.
There aren't requirements, however given that our software is mirrored around the world and our tools are made easy to make your own Fedora, it's possible that somebody could start handing out spoofed Fedoras. If the key you're asking to import says it's Fedora, but the public key servers don't match this key, that's a very quick indication that you should stop using the system as it's been compromised in some way.
Also it's easy enough to install some piece of software off the net that drops a yum repo file in place and starts handing you packages from another repo. You should get the opportunity to confirm your trust in this repo before it starts replacing all kinds of packages in your system.. (now said packages that drop a repo file could just easily set gpgcheck=no and bypass all the trust issues, but that's neither here nor there)
I will happily admit that our dialogs don't say any of this and just assume that the user "gets" all this automatically.
On 22/08/07, Jesse Keating jkeating@redhat.com wrote:
Also it's easy enough to install some piece of software off the net that drops a yum repo file in place and starts handing you packages from another repo. You should get the opportunity to confirm your trust in this repo before it starts replacing all kinds of packages in your system.. (now said packages that drop a repo file could just easily set gpgcheck=no and bypass all the trust issues, but that's neither here nor there)
I think it is very important actually. If a malicious package is putting files in random places as the root user (installing a package manually using rpm) then we've essentially lost security on the system as far as I'm concerned.
You could take this argument one step further and a malicious package could be designed to patch yum/rpm to not do the gpg checks.
Richard.
On Wed, 22 Aug 2007 13:44:31 -0400 Christopher Aillon caillon@redhat.com wrote:
Why isn't Fedora's key imported by default?
For the reason I listed above, we don't control the distribution of Fedora. We hand it out to mirrors and encourage people download it from !us. We can import the RHEL key by default because we control the distribution mechanism. You can only get RHEL through us.
On Wed, 2007-08-22 at 13:53 -0400, Jesse Keating wrote:
On Wed, 22 Aug 2007 13:44:31 -0400 Christopher Aillon caillon@redhat.com wrote:
Why isn't Fedora's key imported by default?
For the reason I listed above, we don't control the distribution of Fedora. We hand it out to mirrors and encourage people download it from !us. We can import the RHEL key by default because we control the distribution mechanism. You can only get RHEL through us.
Assume that Alice gets Fedora from Mallory's mirror. What prevents Mallory from patching the rpm and yum programs that end up on Alice's system to avoid honoring the keys that we, painfully, make her import?
David
On Wed, 2007-08-22 at 13:53 -0400, David Zeuthen wrote:
On Wed, 2007-08-22 at 13:53 -0400, Jesse Keating wrote:
On Wed, 22 Aug 2007 13:44:31 -0400 Christopher Aillon caillon@redhat.com wrote:
Why isn't Fedora's key imported by default?
For the reason I listed above, we don't control the distribution of Fedora. We hand it out to mirrors and encourage people download it from !us. We can import the RHEL key by default because we control the distribution mechanism. You can only get RHEL through us.
Assume that Alice gets Fedora from Mallory's mirror. What prevents Mallory from patching the rpm and yum programs that end up on Alice's system to avoid honoring the keys that we, painfully, make her import?
(and if the answer is "Alice checks the MD5 sum of the ISO against something from an official Fedora website that she trusts" (unlikely, but..) then you just proved my case that including the GPG keys on the ISO itself is fine too.)
David
On Wed, 22 Aug 2007 13:53:40 -0400 David Zeuthen davidz@redhat.com wrote:
Assume that Alice gets Fedora from Mallory's mirror. What prevents Mallory from patching the rpm and yum programs that end up on Alice's system to avoid honoring the keys that we, painfully, make her import?
I honestly don't have an answer for this. They could. Should we then just throw out any and all verification utilities? That would make life easier.
On 8/22/07, Jesse Keating jkeating@redhat.com wrote:
On Wed, 22 Aug 2007 13:53:40 -0400 David Zeuthen davidz@redhat.com wrote:
Assume that Alice gets Fedora from Mallory's mirror. What prevents Mallory from patching the rpm and yum programs that end up on Alice's system to avoid honoring the keys that we, painfully, make her import?
I honestly don't have an answer for this. They could. Should we then just throw out any and all verification utilities? That would make life easier.
No, that's not the point. The MD5 checksum we have in place now are useful and should be kept. The point is that with those measures in place, why don't we just ship the Fedora GPG by default?
Kristian
On Wed, 22 Aug 2007 14:15:30 -0400 "Kristian Høgsberg" krh@bitplanet.net wrote:
No, that's not the point. The MD5 checksum we have in place now are useful and should be kept. The point is that with those measures in place, why don't we just ship the Fedora GPG by default?
*shrug* I'm rapidly losing energy for this talk, and thus I can't think of too many reasonable reasons why not. If there is an overwhelming desire to do this, I won't stand in the way, but we should do it for Fedora in general and not as a change just for the Desktop Live image. (and I'd like to get the input from our security folks too)
On Wed, 2007-08-22 at 14:28 -0400, Jesse Keating wrote:
On Wed, 22 Aug 2007 14:15:30 -0400 "Kristian Høgsberg" krh@bitplanet.net wrote:
No, that's not the point. The MD5 checksum we have in place now are useful and should be kept. The point is that with those measures in place, why don't we just ship the Fedora GPG by default?
*shrug* I'm rapidly losing energy for this talk, and thus I can't think of too many reasonable reasons why not. If there is an overwhelming desire to do this, I won't stand in the way, but we should do it for Fedora in general and not as a change just for the Desktop Live image. (and I'd like to get the input from our security folks too)
Sure. Against which component should we file a bug?
David
On Wed, 22 Aug 2007 14:30:22 -0400 David Zeuthen davidz@redhat.com wrote:
Sure. Against which component should we file a bug?
I'm not entirely sure where we'd want to do this. It has to be ran as the root user on the system (or somebody with sudo access) after the install has completed. Anaconda? Firstboot?
On Wed, 2007-08-22 at 14:38 -0400, Jesse Keating wrote:
On Wed, 22 Aug 2007 14:30:22 -0400 David Zeuthen davidz@redhat.com wrote:
Sure. Against which component should we file a bug?
I'm not entirely sure where we'd want to do this. It has to be ran as the root user on the system (or somebody with sudo access) after the install has completed. Anaconda? Firstboot?
Why? Can't we just include the GPG keys in the fedora-release package?
David
On Wed, 22 Aug 2007 14:37:10 -0400 David Zeuthen davidz@redhat.com wrote:
Why? Can't we just include the GPG keys in the fedora-release package?
We do. However we can't import them into the rpm database. Well, /maybe/ we can in %post, but that doesn't sound right.
On Wed, 2007-08-22 at 14:52 -0400, Jesse Keating wrote:
On Wed, 22 Aug 2007 14:37:10 -0400 David Zeuthen davidz@redhat.com wrote:
Why? Can't we just include the GPG keys in the fedora-release package?
We do. However we can't import them into the rpm database. Well, /maybe/ we can in %post, but that doesn't sound right.
That's what I meant, yeah %post. I've filed
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253897
to track this. Thanks.
David
On 8/22/07, David Zeuthen davidz@redhat.com wrote:
Assume that Alice gets Fedora from Mallory's mirror. What prevents Mallory from patching the rpm and yum programs that end up on Alice's system to avoid honoring the keys that we, painfully, make her import?
would signing our mirror metadata help? would importing the provided keys at install time help? (We have to assume the install media is trusted)
-jef
On Wed, 2007-08-22 at 13:13 -0800, Jeff Spaleta wrote:
On 8/22/07, David Zeuthen davidz@redhat.com wrote:
Assume that Alice gets Fedora from Mallory's mirror. What prevents Mallory from patching the rpm and yum programs that end up on Alice's system to avoid honoring the keys that we, painfully, make her import?
would signing our mirror metadata help?
Hmm... Lets say someone is doing a MITM attack on your yum mirrors (probably by replacing the mirrorlist with a list of their servers, or using DNS tricks to point everything to them). What can they do? They can certainly hide updates, giving you an outdated view of the repo so you don't get any security updates. Anything else?
Anyway, I think every file on the mirrors should be signed somehow, and everything downloaded by yum, Anaconda or the bootstrap code on boot.iso and all the other ISOs should be checked against against a public key included on the boot media. So basically, if you have a trusted CD containing boot.iso, your install would potentially be totally secure.
Btw, RHEL should do this too, because both with RHEL and Fedora, if you do an FTP install, there's no verification of the packages, AFAICT. With RHEL, you might have an internal FTP server with the extracted OS distribution, but you're still assuming that your network is secure, which is something you should always avoid doing.
would importing the provided keys at install time help? (We have to assume the install media is trusted)
I think the installer should be free to rpm --import anything it puts in /etc/pki, but it probably does not make sense to import rawhide keys etc.
/abo
On 8/22/07, Jesse Keating jkeating@redhat.com wrote:
There aren't requirements, however given that our software is mirrored around the world and our tools are made easy to make your own Fedora, it's possible that somebody could start handing out spoofed Fedoras. If the key you're asking to import says it's Fedora, but the public key servers don't match this key, that's a very quick indication that you should stop using the system as it's been compromised in some way.
Jean is a physics researcher at CERN. He installed Fedora on his workstation because he's developing some parallel computation software related to his hypothesis using MPI, and he likes Linux as a development environment. He is helping to discover the fundamental properties of the universe.
Jean is smarter than anyone posting in this thread.
People keep making the assumption that reducing questions is designing for "dumb" users. In fact, we're designing for users who have *more important things to do*.
We should make sure we're not stopping Jean in the middle of his work with a question like "Do you trust this hex number?". It's not that he couldn't answer it, but we certainly don't make it easy to do so "correctly" (which I guess is browsing to pgp.mit.edu and manually entering the hex number and making some sort of wild guess based on other signatures).
The obvious default policy to me is:
* Fedora trusts the GPG keys it ships * All other keys are denied
The scenario where this does break down is installing software from other sites like livna. If we have some sort of hoop there in the process that's probably fine. Maybe you have to "sudo rpm -ivh http://livna.org/gpg.asc", or click some dialog. Firefox makes users installing extensions wait 3 seconds.
What I would do is be very realistic though - 99.99% of people are just going to click "OK" to random dialogs popping up, and there is nothing we can do to change that.
Also it's easy enough to install some piece of software off the net
that drops a yum repo file in place and starts handing you packages from another repo.
If you installed an RPM from an untrusted source, you have already lost. It can execute arbitrary code in %post, or overwrite /lib/libc.so, the possibilities are endless.
On Wed, 22 Aug 2007 13:55:19 -0400 "Colin Walters" walters@redhat.com wrote:
If you installed an RPM from an untrusted source, you have already lost. It can execute arbitrary code in %post, or overwrite /lib/libc.so, the possibilities are endless.
So basically what you're saying is that we should just give up and go home. Right? Do we seriously just want to give everybody full root access and let whatever happens happens, never asking them to think a second about what they're clicking or doing? Basically windows95/98 mentality?
"Oh, well we'll just allow them to install software from configured repos." That's great, how do you add repos, because Fedora by design doesn't have everything a user wants. "Oh, we'll well just allow them to install a package from a website that has the repo files in it." Game over.
Hey it'd be neat if we didn't have to think about security anymore. We could focus on a lot of the other cool stuff we want to do. No questions, no checking, just have at it!
On Wed, 2007-08-22 at 14:01 -0400, Jesse Keating wrote:
Hey it'd be neat if we didn't have to think about security anymore. We could focus on a lot of the other cool stuff we want to do. No questions, no checking, just have at it!
To me, that's totally not what Colin is suggesting. In fact, there are things in his mail that actually suggests to *improve* security such as replacing, IMO, useless dialogs like "Import this GPG key: <hexnumber>" to something more useful (his proposal about timeouts). See also my other mail about asking better questions like "Import this GPG key: <hexnumber>".
David
On Wed, 22 Aug 2007 14:02:47 -0400 David Zeuthen davidz@redhat.com wrote:
To me, that's totally not what Colin is suggesting. In fact, there are things in his mail that actually suggests to *improve* security such as replacing, IMO, useless dialogs like "Import this GPG key: <hexnumber>" to something more useful (his proposal about timeouts). See also my other mail about asking better questions like "Import this GPG key: <hexnumber>".
I got from it that he just wants to do away with the question entirely. I'm having a hard time figuring out where you guys want to go. In one hand you say you don't want dialogs at all that ask people to think or even respond, it just does things. On the other you say as soon as you allow installing software that is outside of the repos we ship, the jig is up and we shouldn't care about any sort of security form that point on. I'm lost :(
On Wed, 2007-08-22 at 14:11 -0400, Jesse Keating wrote:
On Wed, 22 Aug 2007 14:02:47 -0400 David Zeuthen davidz@redhat.com wrote:
To me, that's totally not what Colin is suggesting. In fact, there are things in his mail that actually suggests to *improve* security such as replacing, IMO, useless dialogs like "Import this GPG key: <hexnumber>" to something more useful (his proposal about timeouts). See also my other mail about asking better questions like "Import this GPG key: <hexnumber>".
I got from it that he just wants to do away with the question entirely. I'm having a hard time figuring out where you guys want to go. In one hand you say you don't want dialogs at all that ask people to think or even respond, it just does things. On the other you say as soon as you allow installing software that is outside of the repos we ship, the jig is up and we shouldn't care about any sort of security form that point on. I'm lost :(
That's not how I read the thread. Basically
- We should include Fedora GPG keys by default. See https://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00285.htm... why this is a good idea.
- Have some dialogs that are actually *useful* when you try to install software that comes from outside Fedora. See https://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00274.htm... https://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00279.htm... for some ideas.
Is it more clear now?
David
On 8/22/07, Jesse Keating jkeating@redhat.com wrote:
On Wed, 22 Aug 2007 14:02:47 -0400 David Zeuthen davidz@redhat.com wrote:
To me, that's totally not what Colin is suggesting. In fact, there are things in his mail that actually suggests to *improve* security such as replacing, IMO, useless dialogs like "Import this GPG key: <hexnumber>" to something more useful (his proposal about timeouts). See also my other mail about asking better questions like "Import this GPG key: <hexnumber>".
I got from it that he just wants to do away with the question entirely. I'm having a hard time figuring out where you guys want to go. In one hand you say you don't want dialogs at all that ask people to think or even respond, it just does things. On the other you say as soon as you allow installing software that is outside of the repos we ship, the jig is up and we shouldn't care about any sort of security form that point on. I'm lost :(
You are missing the fact that the action we take without asking the user doesn't have to be "accept" it can be "deny". And "deny" doesn't mean that "we're taking capabilities away from the user", it means "people are forced to think about how this really should have worked". Asking the user is usually a cop-out for bad design and laziness.
For example, imagine that we enhance our system so that so anyone can have a one click link on their website to add their GPG key and yum repository, and we've done the work so:
A) The information displayed to the user has been audited to be accurate B) We provide some sort of reputation system displayed right along with the question so that you have a basis for an informed decision C) We check that you are downloading the information over a secure channel
Then Livna can put such a link on their web site along with instructions. And it works out vastly better rather than asking someone if they like a hex string or not.
- Owen
On 8/22/07, Owen Taylor otaylor@redhat.com wrote:
A) The information displayed to the user has been audited to be accurate
You have a proposal on how to do this? I have grave concerns about being legally allowed to do this in a centralize way as part of the Fedora project.
B) We provide some sort of reputation system displayed right along with the question so that you have a basis for an informed decision
Uhm... probably not possible. I seriously doubt that we could officially host a ranking of 3rd party sources in fedora controlled infrastructure. We go out of our way to not officially communicate about 3rd party repos. I have a very hard time seeing how this is going to be integrated into a Fedora experience with the Fedora Project acting as the central broker of reputation.
-jef
On 8/22/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 8/22/07, Owen Taylor otaylor@redhat.com wrote:
A) The information displayed to the user has been audited to be accurate
You have a proposal on how to do this? I have grave concerns about being legally allowed to do this in a centralize way as part of the Fedora project.
The larger point about gpg import questions is really unchanged if there's no way to do a central authority. If we can't do a central authority, that just means you have to ask about "import GPG blah blah" and not "do you trust the Fedora Project?", and "import GPG blah blah" is NOT good enough / useful / a solution _at all_. The point is _not_ that a question about "import GPG" is suboptimal; the point is that it's useless and probably even actively harmful. At least that would be _my_ point, if it wasn't someone else's. ;-)
Dialogs just are not security. If your software design is insecure if you don't ask, then your system is also insecure if you do ask, because as an empirical matter some huge percentage of people - including very tech-savvy people - will always click yes as a habit.
Dialogs are for programmers to cover their own ass and blame the user. They do not do much at all to actually stop whether people become victims of security exploits, _in practice_.
A dialog that's human readable (says "Fedora Project" not "GPG blah blah") _might_ be useful for a few more people than one with the GPG stuff, the non-human-readable one is useful for essentially nobody. But fundamentally it's still pretty weak security.
A secure design either forbids unsigned stuff in a strong, almost-impossible-to-override way; or is secure despite unsigned stuff.
Which in practice afaik means either a central signing authority (or at least some kind of web of trust or definition of which keys you trust), or you sandbox whatever is downloaded.
No secure solution I've ever seen involves dialogs as a critical element.
Havoc
On 8/22/07, Havoc Pennington hp@redhat.com wrote:
The larger point about gpg import questions is really unchanged if there's no way to do a central authority.
I don't disagree. But I'm not sure we have the freedom to centralize such an authority inside the fedora project, given my current understanding of how we are allowed to interact with 3rd party repositories. I'm concerned that legal will need to review any such plans. I also don't think we can realistically externalize such authority and expect such an external authority to play a central role out of the box.
On 8/22/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 8/22/07, Owen Taylor otaylor@redhat.com wrote:
A) The information displayed to the user has been audited to be accurate
You have a proposal on how to do this? I have grave concerns about being legally allowed to do this in a centralize way as part of the Fedora project.
Now, I have no competence to address the legality, but there is a big difference between providing a listing of third party repositories as compared, to, when queried say "Yes, Joe Smith's Package Repository is in fact an accurate description of this .repo file" The latter can even be done without storing *any* information about Joe Smith's Package Repository on the Fedora repository by instead storing a GPG keyring of people trusted to do such audits and sign the information.
B) We provide some sort of reputation system displayed right along with the question so that you have a basis for an informed decision
Uhm... probably not possible. I seriously doubt that we could officially host a ranking of 3rd party sources in fedora controlled infrastructure. We go out of our way to not officially communicate about 3rd party repos. I have a very hard time seeing how this is going to be integrated into a Fedora experience with the Fedora Project acting as the central broker of reputation.
Well, there is one form of reputation system that I'm sure would pass muster ... a blacklist of known bad sites. But I'm pretty sure you can go further than that without running legal risks if you have no listing of sites and no "recommendation", and just display the data when the user is going to install the .repo file / GPG key. All you really need to store is:
- Number of times the repo file / GPG key has been installed - Number of problem reports - Ability to click and view the problem reports
So you wouldn't be endorsing Joe Smith's Package Repository at all, but if someone found a link to it, they'd be able to see the stats that 10,000 other people have installed the package repository, and 10 people have reported problems. People could draw their own conclusion from that whether it was a safe repository to install. Remember, we don't need to answer the question "what are cool repos to add", we just need to answer the question "is this repo that I'm trying to add safe or not".
- Owen
On 8/22/07, Owen Taylor otaylor@redhat.com wrote:
So you wouldn't be endorsing Joe Smith's Package Repository at all,
Putting aside the debate of popularity != safety for the time being....
We don't have to "endorse" to run afoul of legal issues. Merely helping users compile a list of any 3rd party repositories is potentially off-limits. Can you point to anything we are doing right now, where we make any effort at all to comprehensively list 3rd party repositories inside the official fedora project space.. even in the wiki.. even without using urls? My understanding is that we aren't even allowed to do that.
Even a simple list of repository entities, with absolutely no contextual information concern the quality or scope of their contents, may be beyond the bounds of what we are allowed to provide. Any reputation system inherently involves making such a list and then adding contextual information. "This repo exists" maybe a statement that is beyond what we are capable of saying in any official capacity.
-jef"hopes we can implement this, so I can game the system and make my repository of deliberately malformed packages appear to be safe by installing 100,000 or so virtual machines and give them all unique smolt ids and have a bug tracker that reports back zero bugs found against all queries"spaleta
On 8/22/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 8/22/07, Owen Taylor otaylor@redhat.com wrote:
So you wouldn't be endorsing Joe Smith's Package Repository at all,
Putting aside the debate of popularity != safety for the time being....
We don't have to "endorse" to run afoul of legal issues. Merely helping users compile a list of any 3rd party repositories is potentially off-limits. Can you point to anything we are doing right now, where we make any effort at all to comprehensively list 3rd party repositories inside the official fedora project space.. even in the wiki.. even without using urls? My understanding is that we aren't even allowed to do that.
OK, so store everything indexed by one-way hash of a repo GUID, so there is no way of mapping back from what is on the server to the 3rd party repository at all, even if you have access to the raw data files on our server...
I'm sure we can work with legal to come up with something acceptable.
- Owen
On 8/22/07, Owen Taylor otaylor@redhat.com wrote:
I'm sure we can work with legal to come up with something acceptable.
I hope so. I just want to make sure you guys don't go crazy on implementation mock-ups just to get your bubbles bursted by the non-technical constraints.
End of the day reality: the gpg importation dialogs that we have are pretty meaninglist to self-admining users. Being able to offer some sort of measure of "trust" in the validity of repository keys would do a lot and would allow us to deny importation and redirect users to our authority site for an explanation of the denial.
Though how we handle local network repositories that we can't act as an authority for...that's a tougher question. It's easy to forget that .edus and even .coms can and will have internal repositories that desktop installs will be encouraged to use. These repos are absolutely and utterly hidden from scrutiny from any public authority.
I still think there are some inherent problems with reputation associated with any definition of "safety", but we've got months to argue over that if things come to that.
-jef
On 8/22/07, Jeff Spaleta jspaleta@gmail.com wrote:
It's easy to forget that .edus and even .coms can and will have internal repositories that desktop installs will be encouraged to use. These repos are absolutely and utterly hidden from scrutiny from any public authority.
Yes, but those people will ensure that people using the systems have the requisite keys preinstalled. At least they will if they're at all sane.
On 8/22/07, Colin Walters walters@redhat.com wrote:
Yes, but those people will ensure that people using the systems have the requisite keys preinstalled. At least they will if they're at all sane.
I think its comical to suggest that people who run repos inside large .edu networks, have the ability to ensure their userbase will have keys pre-installed. Don't neglect the hundreds of edu repos that exist just because Fedora can't see them.
-jef"Go to the nearest college or university that as a Division 1 football team, and interact with a random sampling of first year students to re-calibrate your user expectations inside edu network firewalls."spaleta
On 23/08/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 8/22/07, Owen Taylor otaylor@redhat.com wrote:
I'm sure we can work with legal to come up with something acceptable.
I hope so. I just want to make sure you guys don't go crazy on implementation mock-ups just to get your bubbles bursted by the non-technical constraints.
Ohh, it's entirely doable in the current PackageKit design, it's just an argument on whether it's a good idea to do so or not.
What I'm currently thinking is:
User installs livna/internal/freshrpms repo rpm User types in mplayer into application finder User clicks install
PackageKit gets the GPG key message, and returns an error enum gpg-key-required and the description of the repo as the technical data. The install "fails" and a dialog is presented to the user.
Then, as a seporate task the user can click on the button in the failure GUI and the GPG key can be imported (using PolicyKit as auth?). Then the install can be retried and should succeed.
Sounds insane to me, but allows us to keep (and further improve) the GPG repo signed issue if we want to, or have to, keep it.
Richard.
On Thu, 2007-08-23 at 02:23 +0100, Richard Hughes wrote:
On 23/08/07, Jeff Spaleta jspaleta@gmail.com wrote:
On 8/22/07, Owen Taylor otaylor@redhat.com wrote:
I'm sure we can work with legal to come up with something acceptable.
I hope so. I just want to make sure you guys don't go crazy on implementation mock-ups just to get your bubbles bursted by the non-technical constraints.
Ohh, it's entirely doable in the current PackageKit design, it's just an argument on whether it's a good idea to do so or not.
What I'm currently thinking is:
User installs livna/internal/freshrpms repo rpm User types in mplayer into application finder User clicks install
PackageKit gets the GPG key message, and returns an error enum gpg-key-required and the description of the repo as the technical data. The install "fails" and a dialog is presented to the user.
Then, as a seporate task the user can click on the button in the failure GUI and the GPG key can be imported (using PolicyKit as auth?). Then the install can be retried and should succeed.
Sounds insane to me, but allows us to keep (and further improve) the GPG repo signed issue if we want to, or have to, keep it.
Sounds sane to me actually. Initially I'd just show the GPG key and name and link to a bunch of disclaimers/explanations; it will be pretty useless initially but on par with what yum / pirut does [1].
I like the idea that GPG importing is a separate application (but should still live in the PackageKit tarball/repository IMO); it makes it easier for contributors to hack on it to land some of the ideas about trust metrics etc.
Regarding abstraction, does the other packaging formats and/or depsolvers work in a similar way? Something to think about.
David
[1] : http://www.pro-linux.de/berichte/jpgs/fc5-test2/fc5-pirut.png
Jeff Spaleta wrote:
On 8/22/07, Owen Taylor otaylor@redhat.com wrote:
I'm sure we can work with legal to come up with something acceptable.
I hope so. I just want to make sure you guys don't go crazy on implementation mock-ups just to get your bubbles bursted by the non-technical constraints.
End of the day reality: the gpg importation dialogs that we have are pretty meaninglist to self-admining users. Being able to offer some sort of measure of "trust" in the validity of repository keys would do a lot and would allow us to deny importation and redirect users to our authority site for an explanation of the denial.
Though how we handle local network repositories that we can't act as an authority for...that's a tougher question. It's easy to forget that .edus and even .coms can and will have internal repositories that desktop installs will be encouraged to use. These repos are absolutely and utterly hidden from scrutiny from any public authority.
I still think there are some inherent problems with reputation associated with any definition of "safety", but we've got months to argue over that if things come to that.
-jef
Dumb question - would it be possible to sign the gpg keys of the repos with the Fedora key, and then report the signature as part of the import dialog? (I know it can be done technically, but I am not sure how practical/legal it would be...)
Mikkel
On 8/22/07, Jesse Keating jkeating@redhat.com wrote:
So basically what you're saying is that we should just give up and go home. Right? Do we seriously just want to give everybody full root access and let whatever happens happens, never asking them to think a second about what they're clicking or doing? Basically windows95/98 mentality?
Right now you can install new software on Fedora 7 out of the box - without entering a password - by browsing to: http://addons.mozilla.org
So, you do not need root access to screw yourself over. Really, everything not under /home (i.e. under "root" control) is basically unimportant infrastructure goo. How do I know this? Because almost every time I've tried to upgrade Fedora something has gone wrong, so I've just preserved my /home, blown away my disk, reinstalled, and reinstated /home and been at basically the same point I was before. Just have to enable passwordless sudo.
No one has really solved the problem of trojan software. Dialogs are definitely not a solution. Now, we can have a dialog for it and I wouldn't argue against it - but we shouldn't delude ourselves into thinking that having people enter a password is going to stop them from getting their MP3s to play.
On Wed, 22 Aug 2007 14:17:06 -0400 "Colin Walters" walters@redhat.com wrote:
No one has really solved the problem of trojan software. Dialogs are definitely not a solution. Now, we can have a dialog for it and I wouldn't argue against it - but we shouldn't delude ourselves into thinking that having people enter a password is going to stop them from getting their MP3s to play.
It's not about stopping them from getting mp3s, but whatever.
"We want better dialogs that aren't technobabble". I agree wholeheartedly.
"We want to allow for (and default to) some level of auth before allowing installing software/writing to outside your home dir". Again in agreement.
Your browser question is only so so. Sure you can install stuff to your home dir, but you can't compromise other users on the system.
ons, 22.08.2007 kl. 14.32 -0400, skrev Jesse Keating:
On Wed, 22 Aug 2007 14:17:06 -0400 "Colin Walters" walters@redhat.com wrote:
No one has really solved the problem of trojan software. Dialogs are definitely not a solution. Now, we can have a dialog for it and I wouldn't argue against it - but we shouldn't delude ourselves into thinking that having people enter a password is going to stop them from getting their MP3s to play.
It's not about stopping them from getting mp3s, but whatever.
"We want better dialogs that aren't technobabble". I agree wholeheartedly.
"We want to allow for (and default to) some level of auth before allowing installing software/writing to outside your home dir". Again in agreement.
Your browser question is only so so. Sure you can install stuff to your home dir, but you can't compromise other users on the system.
And for the desktop spin...how many other users are there on the system normally?
Cheers Kjartan
On Fri, 31 Aug 2007 00:30:51 +0200 Kjartan Maraas kmaraas@broadpark.no wrote:
And for the desktop spin...how many other users are there on the system normally?
I don't know, I share my laptop with my family a lot for quick things. A home workstation is probably used by more than one member of the family.
On Wed, 2007-08-22 at 13:55 -0400, Colin Walters wrote:
On 8/22/07, Jesse Keating jkeating@redhat.com wrote:
There aren't requirements, however given that our software is mirrored around the world and our tools are made easy to make your own Fedora, it's possible that somebody could start handing out spoofed Fedoras. If the key you're asking to import says it's Fedora, but the public key servers don't match this key, that's a very quick indication that you should stop using the system as it's been compromised in some way.Jean is a physics researcher at CERN. He installed Fedora on his workstation because he's developing some parallel computation software related to his hypothesis using MPI, and he likes Linux as a development environment. He is helping to discover the fundamental properties of the universe.
Jean is smarter than anyone posting in this thread.
People keep making the assumption that reducing questions is designing for "dumb" users. In fact, we're designing for users who have *more important things to do*.
We should make sure we're not stopping Jean in the middle of his work with a question like "Do you trust this hex number?". It's not that he couldn't answer it, but we certainly don't make it easy to do so "correctly" (which I guess is browsing to pgp.mit.edu and manually entering the hex number and making some sort of wild guess based on other signatures).
If which key is available as part of the metadata for the packages, we could flag the packages as being signed, but not verified in the UI. Some simple integration with seahorse could then help import specific keys from pgp.mit.edu, and for people to be able to verify the key before importing.
On Wed, 2007-08-22 at 13:55 -0400, Colin Walters wrote:
The obvious default policy to me is:
- Fedora trusts the GPG keys it ships
- All other keys are denied
I'd say:
* PackageKit trusts the GPG keys that are in /etc/pki. * All other keys are denied.
Yum, on the other hand, does ask and show a fingerprint, but it also shows the path to the key (IIRC), so the smart user can see if it's a trusted key from /etc/pki or if it's an unknown key that she needs to check.
The scenario where this does break down is installing software from other sites like livna. If we have some sort of hoop there in the process that's probably fine. Maybe you have to "sudo rpm -ivh http://livna.org/gpg.asc", or click some dialog. Firefox makes users installing extensions wait 3 seconds.
Yup. Which is basically what we have today. You do
rpm -ivh http://www.3dparty.org/3rdpart-release.rpm
That puts the key in /etc/pki, which means you've agreed to trust it. As long as 3dparty.org is a good repo and you're net being MITM:d, it's fine. And it's a manual step that requires doing stuff in a root shell or responing with the root password when you click on the rpm link in the browser. There's room for improvement here though, perhaps if some legally and technically sane way of helping the use figure out who to trust can be found.
/abo
On Sat, 2007-09-01 at 10:05 +0200, Alexander Boström wrote:
- PackageKit trusts the GPG keys that are in /etc/pki.
- All other keys are denied.
Guys, if people want to talk about implementation, could you please join the mailing list, and we can talk there with the other devs. The mailing list is http://lists.freedesktop.org/mailman/listinfo/packagekit
Thanks.
Richard.
desktop@lists.stg.fedoraproject.org
-
Alexander Boström -
Bastien Nocera -
Christopher Aillon -
Colin Walters -
David Zeuthen -
Havoc Pennington -
Jef Spaleta -
Jesse Keating -
Kjartan Maraas -
Kristian Høgsberg -
Mikkel -
Owen Taylor -
Richard Hughes