Re: Requesting UI Freeze break for gnome-panel and gnome-utils
On Mon, 2007-08-27 at 19:35 -0600, Elijah Newren wrote: > > > > Can I apply the two patches? > > > Clearly, something has to be done. I suppose our options are: > > > > 1) Just make the icon change > > 2) Put the old icons back somewhere > > > I say we make the change. > > Due to Shaun being behind it and his reasoning, here's another > approval to go with Vincent's to give you 2 of 2 approvals. thanks, committed the patch for the dictionary. I left the icon in SVN, though, so it's easy to revert. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requesting UI Freeze break for gnome-panel and gnome-utils
On Tue, 2007-08-28 at 00:40 +0200, Sebastian Pölsterl wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jaap Haitsma schrieb: > > Hi, > > > > The gnome-searchtool icon got removed from gnome-icon-theme because it > > got replaced by the system-search icon. > > > Good to know. Deskbar-Applet uses the icon as well. So the icon should > get replaced there, too. This is starting to sound like a disaster waiting to happen. Is there any way to grep for a string in the trunk of all our SVN repos, short of checking them all out? That way we could find all references to an icon before it gets removed. (I could see other uses of this, like finding all links to a User Guide section before we remove or rename it.) -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requesting UI Freeze break for gnome-panel and gnome-utils
Shaun McCance wrote: > (I could see other uses of this, like finding all links to > a User Guide section before we remove or rename it.) If you are interested I can probably get this information when building library.gnome.org. Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requesting UI Freeze break for gnome-panel and gnome-utils
tir, 28.08.2007 kl. 10.55 -0500, skrev Shaun McCance: > On Tue, 2007-08-28 at 00:40 +0200, Sebastian Pölsterl wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Jaap Haitsma schrieb: > > > Hi, > > > > > > The gnome-searchtool icon got removed from gnome-icon-theme because it > > > got replaced by the system-search icon. > > > > > Good to know. Deskbar-Applet uses the icon as well. So the icon should > > get replaced there, too. > > This is starting to sound like a disaster waiting to happen. > Is there any way to grep for a string in the trunk of all > our SVN repos, short of checking them all out? That way we > could find all references to an icon before it gets removed. > codesearch.google.com? Other than that I still miss the LXR setup we had back in the day. It was very useful. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gedit-plugins branched for gnome 2.18
Hello, gedit-plugins has just been branched. Gnome 2.20 development will happen in HEAD. Note that gedit-plugins is not part of the gnome release. Plans are to adapt gedit-plugins to the new gedit/gtksourceview API. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
cleaning up keyrings
Hi, Looking for pointers to people working on the following or who have had ideas on the following. When doing "create new account, use desktop from scratch" tests, you quickly notice you're typing the same password a bunch of times (e.g. gmail in browser, gmail/calendar in bigboard, gtalk in pidgin or gossip). John Markoff recently did an impromptu Online Desktop using a live CD: http://bits.blogs.nytimes.com/2007/08/24/why-cant-we-compute-in-the-cloud-part-2/ a quote from that: "I found the only things I was missing were the passwords to online databases and my files of past reporting notes and articles which I occasionally refer to." Anyway, I'm thinking about how to clean up the password-storage situation. Here is the current situation: - Pidgin just sticks passwords in plain text in app-specific XML files - Gossip does the same thing, plain text in XML files - Firefox has its whole own thing, though they have plans to use the Keychain on OS X they are not planning to use gnome-keyring according to possibly-outdated wiki page: http://wiki.mozilla.org/Firefox:Password_Manager - BigBoard puts things in gnome-keyring Looking in gnome-keyring-manager, there's barely anything in there. All I have in mine is BigBoard and NetworkManager's VPN feature. (NetworkManager doesn't put WEP keys in there, though, apparently?) Looking at gnome-keyring-manager does hint at one problem, though; gnome-keyring is too "policy free" and free-form. It provides a shared password facility, but no real guideline for _how_ to store the passwords or how to find the password for a particular thing or particular site. The Apple Keychain API is of interest if Firefox is going to try to work with that, so here it is for reference: http://developer.apple.com/documentation/Security/Conceptual/keychainServConcepts/index.html Here is what I think we need: - some specification of how to store passwords in gnome-keyring, i.e. what goes in the fields like "server" and "object" if I have a random XMPP account, AIM account, web site password, and other typical cases. Also, firefox stores the name="" attributes from the username and password input fields, where do those go? - this spec has to support the "account manager" type UI in the IM clients, where you can create N accounts and specify the login/password for each - fix BigBoard to use the spec - fix the IM apps to use the keyring - fix Firefox to use the keyring, or at least let apps query Firefox password manager storage - have some mechanism for "smart deductions," like "I can guess you have an XMPP account that matches your google.com username/password" - maybe this just has to be in the apps, not sure I just started thinking about this today, so let me know what's missing. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
I forgot to mention taking the encrypted keyring blob and sticking it on a server somewhere, but (I think) that's an independent issue from getting everything to use the same keyring and same keyring entries. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
> - have some mechanism for "smart deductions," like "I can guess you > have an XMPP account that matches your google.com username/password" - > maybe this just has to be in the apps, not sure This needs some care. There are evils that lurk on the web side of this. One big one is that if a central service provides a guessed login/password from another source to firefox, I can steal it using javascript into a hidden form which might be bad if I can trigger wrong guesses. For pure web use this problem doesn't normally arise as the URI gives a scope which makes sense, once you take guesses from outside you don't know enough to guess where to paste them. > I just started thinking about this today, so let me know what's missing. One of the things you can use the TPM for in a treacherous computing system is simply as a poor quality smart card. And for that matter working with a proper smart card is similar. Being able to share my keyring simply by - USB - Bluetooth - Internet - Smart Card - TPM (where there is a common root key) including merging entries from multiple sources. PAM already lets me direct sensitive system authentication questions to a seperate trusted display (my phone) which I can't currently do for the other apps. Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On Tue, 2007-08-28 at 17:33 -0400, Havoc Pennington wrote: > Anyway, I'm thinking about how to clean up the password-storage situation. > > Here is the current situation: > - Pidgin just sticks passwords in plain text in app-specific XML files > - Gossip does the same thing, plain text in XML files > - Firefox has its whole own thing, though they have plans to use the > Keychain on OS X they are not planning to use gnome-keyring according > to possibly-outdated wiki page: > http://wiki.mozilla.org/Firefox:Password_Manager As usual, Firefox' integration in the desktop stinks. That's why a number of us use Epiphany. FYI, that's what's missing to get Epiphany to use the gnome-keyring: https://bugzilla.mozilla.org/show_bug.cgi?id=265780 https://bugzilla.mozilla.org/show_bug.cgi?id=351427 from: http://bugzilla.gnome.org/show_bug.cgi?id=130336 Pidgin has the same disease as Firefox, wants to be everywhere, thus is integrated nowhere. OpenSUSE seems to have a patch to make use of the gnome-keyring though. I found it in: ftp://ftp5.gwdg.de/pub/opensuse/repositories/GNOME%3A/UNSTABLE/openSUSE_10.2/src/pidgin-2.1.0-2.3.src.rpm Gossip should really know better though: http://bugzilla.gnome.org/show_bug.cgi?id=343513 Cheers -- Bastien Nocera <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, Thanks for the bug links, those are helpful. Here are some questions I have about conventions for storing stuff in the keyring, which would be relevant to the Gossip bug (and future similar bug against Pidgin, etc.) - when do you use "default"/NULL vs. "session" keyring? (I think I've asked this before, but I forget) - the Gossip patch sets user=havoc.pennington and server=gmail.com for my account, but why does it set "server" and not "domain", and when would something set "domain"? Is "domain" intended for web passwords only? - what is the "object" field in gnome-keyring supposed to be for? NetworkManager vpn stuff sets it to "password" and "group_password", the Gossip patch doesn't use it - Gossip patch sets "protocol" field to "jabber", NetworkManager to "org.freedesktop.NetworkManager.vpnc", ... ? when is this field used and what's its intended content? - I would think in Gossip or Pidgin you can create two accounts with the same username/password (true? or do they stop you?) - how would that be handled? Ideally I think we'd allow Gossip and Pidgin to ask something like "give me all XMPP accounts on the keyring," I guess that would use the "protocol" field? Would the results be sane if Gossip or Pidgin "merged" this resulting list of accounts with their own app-specific list of accounts? How should that merge be done? What if you delete an account in the app's account manager screen? A specific use-case is that if I've already logged in to Google in either Firefox or BigBoard, I think Gossip or Pidgin when first started up should default to knowing that same account info. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On Tue, 2007-08-28 at 22:56 +0100, Bastien Nocera wrote: > Gossip should really know better though: > http://bugzilla.gnome.org/show_bug.cgi?id=343513 FWIW, Gajim uses the keyring. Which is nice. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Havoc Pennington wrote: > I forgot to mention taking the encrypted keyring blob and sticking it > on a server somewhere, but (I think) that's an independent issue from > getting everything to use the same keyring and same keyring entries. Well there are obviously security issues to this. Perhaps there should be a way of having a single certain keyring (with a given name) stored online, and applications could choose whether or not to store passwords in that keyring. My reasoning is in part because, in the next cycle gnome-keyring is getting support for encryption keys (SSH, X509). If those were stored online, it would negate their value a good deal. If encryption keys were downloadable using a password, then why use an encryption key for things like SSH at all? Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On 8/28/07, Havoc Pennington <[EMAIL PROTECTED]> wrote: > (NetworkManager doesn't put WEP keys in there, though, apparently?) This was bogus, I just forgot I was looking at my desktop which has a wired network ;-) Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Alan Cox wrote: >> I just started thinking about this today, so let me know what's missing. > > One of the things you can use the TPM for in a treacherous computing > system is simply as a poor quality smart card. And for that matter > working with a proper smart card is similar. Being able to share my > keyring simply by > > - USB > - Bluetooth > - Internet > - Smart Card > - TPM (where there is a common root key) > > including merging entries from multiple sources. PAM already lets me > direct sensitive system authentication questions to a seperate trusted > display (my phone) which I can't currently do for the other apps. You can do this via USB today with gnome-keyring. There's currently not much UI for it (I'd like to implement the UI properly), but it should work: http://live.gnome.org/GnomeKeyring/Removable If properly thought out, it seems Internet storage of a keyring could work in a similar way. More on this later... Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Havoc Pennington wrote: > Anyway, I'm thinking about how to clean up the password-storage situation. > > Here is the current situation: > - Pidgin just sticks passwords in plain text in app-specific XML files > - Gossip does the same thing, plain text in XML files > - Firefox has its whole own thing, though they have plans to use the > Keychain on OS X they are not planning to use gnome-keyring according > to possibly-outdated wiki page: > http://wiki.mozilla.org/Firefox:Password_Manager I believe the epiphany guys have been working on this, at some point: http://bugzilla.gnome.org/show_bug.cgi?id=130336 > - BigBoard puts things in gnome-keyring > > Looking in gnome-keyring-manager, there's barely anything in there. Yeah, one big problem with gnome-keyring was the problem of having to enter your password twice, which really bugged users. I hope that with the PAM integration in 2.20, this major excuse for not using gnome-keyring will be no more. Evolution, for example, has gnome-keyring support but is rarely compiled with it due to the above. > Looking at gnome-keyring-manager does hint at one problem, though; > gnome-keyring is too "policy free" and free-form. It provides a shared > password facility, but no real guideline for _how_ to store the > passwords or how to find the password for a particular thing or > particular site. Yes a spec does seem necessary to help coordinate what is stored in each of the individual attributes. We ran into this problem with seahorse and gnome-gpg, each of which wanted to store passwords for PGP keys in the keyring. We probably also want to add one or more keyring item types, eg: for web form data. The current list of item types: GNOME_KEYRING_ITEM_GENERIC_SECRET GNOME_KEYRING_ITEM_NETWORK_PASSWORD GNOME_KEYRING_ITEM_NOTE > - have some mechanism for "smart deductions," like "I can guess you > have an XMPP account that matches your google.com username/password" - > maybe this just has to be in the apps, not sure Along with what Alan said, pushing this too far down the stack opens up many possibilities for password retrieval attacks, like the recent spate of attacks that exploited this in Firefox and Safari. Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi Havoc, Cleaning up and making more apps use the keyring is definitely a worthwhile effort in my mind. On Tue, 2007-08-28 at 17:33 -0400, Havoc Pennington wrote: > - fix Firefox to use the keyring, or at least let apps query Firefox > password manager storage > - have some mechanism for "smart deductions," like "I can guess you > have an XMPP account that matches your google.com username/password" - > maybe this just has to be in the apps, not sure One important thing about the gnome-keyring prompts is that they display information the user should be able to trust / understand. Things like that App X is trying to use the key stored by App Y. [1] AFAIK, to do this in a secure way, the prompts stem from a separate process [2] and the code looks at the callers process id to determine what application (on Linux via /proc//exe) is making the requests and then uses that name in prompts like these http://people.freedesktop.org/~david/gnome-keyring-allow-deny.png (actually this instance of the dialog, btw, looks pretty hostile to end users. Maybe I'm just not using gnome-keyring correctly from gnome-mount to save the LUKS pass phrase in the keyring. Shrug.) The key here is that information you show in these prompts absolutely needs to be trusted; you just cannot let the caller of the keyring API pass in random junk; you cannot trust them. So I wonder how this would work with Firefox. Ideally you want to display "The gmail.com website" (and ideally also display some kind of icon whether the website in question is signed by a trusted third-party.) instead of "The application Firefox" As I see it, to do this the keyring prompts would need to trust the Firefox process to get this information or you run the risk of displaying wrong information to the user... Sounds like a pretty hard problem to me. Just some thoughts / ramble. Hope it's useful. David [1] : In fact I'm skeptical that most users will do more than just click through these prompts... if we didn't care about protecting secrets on a per-application basis we would be just as well off with encrypted homedir and just store secrets in plaintext. And then we wouldn't need a keyring API at all. [2] : Which is good as it means it's possible to 1) Restrict access to the keyring database to a specific security context etc. that only the gnome-keyring programs run in; and 2) In the future use of XACE to paint different window decorations to make the dialog look more "trusted" (doubtful approach to security but I thought I'd mention it anyway); and 3) Show the dialogs it on a different X server (e.g. the gdm greeter) possibly using a Secure Attention Key (ctrl+alt+del) to get there. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On Tue, 2007-08-28 at 18:23 -0400, Havoc Pennington wrote: > Hi, > > Thanks for the bug links, those are helpful. > > Here are some questions I have about conventions for storing stuff in > the keyring, which would be relevant to the Gossip bug (and future > similar bug against Pidgin, etc.) I'm not sure anyone's really thought of the conventions behind using each field for something specific. You'd need to ask Alex, he wrote it after all :) > Ideally I think we'd allow Gossip and Pidgin to ask something like > "give me all XMPP accounts on the keyring," I guess that would use the > "protocol" field? Would the results be sane if Gossip or Pidgin > "merged" this resulting list of accounts with their own app-specific > list of accounts? How should that merge be done? What if you delete an > account in the app's account manager screen? Apps would need to agree on what/how to store it. I guess that right now, it's good enough if the app that inserted the details can read it back. > A specific use-case is that if I've already logged in to Google in > either Firefox or BigBoard, I think Gossip or Pidgin when first > started up should default to knowing that same account info. How? I personally log in to google with my personal mail address, don't have any GMail account, and have a @googlemail.com Jabber address. I'm not sure how apps are supposed to link all those (and they'd need access to the cookies, another thing to share, to be able to screenscrape). -- Bastien Nocera <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Havoc Pennington wrote: > - when do you use "default"/NULL vs. "session" keyring? (I think I've > asked this before, but I forget) Use NULL (which automatically maps to the default keyring) when you don't care what keyring a password is stored in, but you want it stored for good. In many cases this will be the 'login' keyring which is automatically unlocked when the user logs into their session. Use 'session' (this should really be a #define in gnome-keyring.h) when something should only be stored for the session. gnome-keyring just got its documentation this cycle (library.gnome.org doesn't seem to have it yet). > - the Gossip patch sets user=havoc.pennington and server=gmail.com > for my account, but why does it set "server" and not "domain", and > when would something set "domain"? Is "domain" intended for web > passwords only? Domain, as far as I know was intended for windows network shares. > - what is the "object" field in gnome-keyring supposed to be for? > NetworkManager vpn stuff sets it to "password" and "group_password", > the Gossip patch doesn't use it This was originally used for the share name in windows network shares, and I've seen it used for for 'paths' underneath the main hostname. > Ideally I think we'd allow Gossip and Pidgin to ask something like > "give me all XMPP accounts on the keyring," I guess that would use the > "protocol" field? Would the results be sane if Gossip or Pidgin > "merged" this resulting list of accounts with their own app-specific > list of accounts? How should that merge be done? What if you delete an > account in the app's account manager screen? So what you're really talking about is storing the concept of an 'account' with all related information in gnome-keyring. So far the focus has been on passwords and secrets. This is certainly possible, but like you said needs a solid spec to get anywhere. The way current applications store information in the keyrings just isn't structured enough. Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, On 8/28/07, Stef Walter <[EMAIL PROTECTED]> wrote: > Havoc Pennington wrote: > > I forgot to mention taking the encrypted keyring blob and sticking it > > on a server somewhere, but (I think) that's an independent issue from > > getting everything to use the same keyring and same keyring entries. > > Well there are obviously security issues to this. > > Perhaps there should be a way of having a single certain keyring (with a > given name) stored online, and applications could choose whether or not > to store passwords in that keyring. Right, I think it would be an option of some kind. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, On 8/28/07, Stef Walter <[EMAIL PROTECTED]> wrote: > > - have some mechanism for "smart deductions," like "I can guess you > > have an XMPP account that matches your google.com username/password" - > > maybe this just has to be in the apps, not sure > > Along with what Alan said, pushing this too far down the stack opens up > many possibilities for password retrieval attacks, like the recent spate > of attacks that exploited this in Firefox and Safari. > I think you guys may understand this backward from what I meant. I am saying if you logged in to google (or Flickr, or whatever) in the browser, then your desktop apps could get at that login info. I'm not saying that the browser could get stuff from the desktop - JavaScript remains sandboxed as usual. (Though as long as somethingis tagged with a domain, and the domain is exact-matched, that might be fine too I would think. But of course it would have to be very carefully defined what the "domain" field means and who sets it.) The functionality I'm after is the same thing we already have for online.gnome.org, where if you are logged in to the web site, then the desktop can use the same cookie to sign on to the XMPP server. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, On 8/28/07, Bastien Nocera <[EMAIL PROTECTED]> wrote: > I'm not sure anyone's really thought of the conventions behind using > each field for something specific. You'd need to ask Alex, he wrote it > after all :) I am hoping he'll read the thread ;-) > > Ideally I think we'd allow Gossip and Pidgin to ask something like > > "give me all XMPP accounts on the keyring," I guess that would use the > > "protocol" field? Would the results be sane if Gossip or Pidgin > > "merged" this resulting list of accounts with their own app-specific > > list of accounts? How should that merge be done? What if you delete an > > account in the app's account manager screen? > > Apps would need to agree on what/how to store it. I guess that right > now, it's good enough if the app that inserted the details can read it > back. That's the point though, I don't think it's really a good situation; if I create a guest account right now, I have to log in to Google three times to get it all going, and that's just one example. Without sharing between apps gnome-keyring doesn't do a whole lot other than throw up allow-or-deny dialogs like Vista. ;-) The ideal is that one local login and one online.gnome.org login is all you need, then your keyring is downloaded and has all other logins. (yes, it will be optional, to head off the inevitable followup) > > A specific use-case is that if I've already logged in to Google in > > either Firefox or BigBoard, I think Gossip or Pidgin when first > > started up should default to knowing that same account info. > > How? I personally log in to google with my personal mail address, don't > have any GMail account, and have a @googlemail.com Jabber address. I'm > not sure how apps are supposed to link all those (and they'd need access > to the cookies, another thing to share, to be able to screenscrape). It won't work if you have a setup like that, or would require more effort to make work. But for example it's easy to make work for my Google setup which is all @gmail.com This isn't something that has to work every time or in every corner case to be useful. It's just something that's nice to do whenever we can. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
the one thing that drives me nuts about gmail is that it doesn't default to reply all... On 8/28/07, Havoc Pennington <[EMAIL PROTECTED]> wrote: > Hi, > > On 8/28/07, Stef Walter <[EMAIL PROTECTED]> wrote: > > So what you're really talking about is storing the concept of an > > 'account' with all related information in gnome-keyring. > > Well, maybe. I was just thinking about that a bit and it seems > probably too ambitious. > > I'd be happy to start if apps could just ask for a list of > username/password pairs by category, like "XMPP", "Google", "Flickr", > or whatever. I think that's enough for apps to do something reasonably > nice. Not sure though. > > > So far the > > focus has been on passwords and secrets. This is certainly possible, but > > like you said needs a solid spec to get anywhere. The way current > > applications store information in the keyrings just isn't structured > > enough. > > Exactly, yep. I can write some simple spec up, but first I want to > understand all the current thinking (so far it sounds like there's a > pretty blank slate for spec'ing this out) > > Havoc > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On Tue, 2007-08-28 at 18:48 -0400, Havoc Pennington wrote: > The functionality I'm after is the same thing we already have for > online.gnome.org, where if you are logged in to the web site, then the > desktop can use the same cookie to sign on to the XMPP server. If cookies are all you want, then all we need is "just" to make (all) the browser and (all) the apps use the same underlying HTTP library, right? David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, On 8/28/07, David Zeuthen <[EMAIL PROTECTED]> wrote: > One important thing about the gnome-keyring prompts is that they display > information the user should be able to trust / understand. Things like > that App X is trying to use the key stored by App Y. [1] Yeah. I'm not sure these dialogs make sense, but for now I'm ignoring them and just worrying about how all apps can share the same login knowledge (you'd still have to allow/deny each app). For why I don't think they make sense, it's pretty much the same issue as https://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00309.html Either you have a secure setup or you don't, dialogs are just a really annoying-to-the-user way of writing "if (TRUE)" and don't affect the security materially. A better approach, for example, would be to have selinux or signatures or something such that apps that come with the OS are automatically trusted and the dialog or other obscure procedure only arises for third-party apps. Then people don't get as used to just clicking "yes" all the time and _might_ slow down for the dialog when it really matters. But, it's a somewhat separate topic from what I was wanting to mess with right away. > [1] : In fact I'm skeptical that most users will do more than just click > through these prompts... if we didn't care about protecting secrets on a > per-application basis we would be just as well off with encrypted > homedir and just store secrets in plaintext. And then we wouldn't need a > keyring API at all. I think the keyring API is most useful for sharing the login info between apps, and potentially storing the login info on a server (or a USB key, or whatever) Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
resend to list... On 8/28/07, Havoc Pennington <[EMAIL PROTECTED]> wrote: > Hi, > > On 8/28/07, David Zeuthen <[EMAIL PROTECTED]> wrote: > > > > On Tue, 2007-08-28 at 18:48 -0400, Havoc Pennington wrote: > > > The functionality I'm after is the same thing we already have for > > > online.gnome.org, where if you are logged in to the web site, then the > > > desktop can use the same cookie to sign on to the XMPP server. > > > > If cookies are all you want, then all we need is "just" to make (all) > > the browser and (all) the apps use the same underlying HTTP library, > > right? > > > > I didn't mean cookies literally, I meant "the thing where you log in > to one conceptual server only one time per desktop session" > > But yes, we need the shared HTTP lib too. ;-) > > Havoc > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
> > Exactly, yep. I can write some simple spec up, but first I want to > > understand all the current thinking (so far it sounds like there's a > > pretty blank slate for spec'ing this out) You might want to have a chat with Dave Howells at Red Hat as well. Dave did the Linux kernel side key management which handles keys on a thread through to user and group level. Documentation/key* in the kernel. This is used to manage keys needed for things like file systems but can be used for other stuff too. It also supports callbacks so the kernel can ask user space about keys. Currently this is used by the ecryptfs and AFS/RXRPC file/net system layers, and also by the MMC/SD layer for managing passwords to encrypted cards. It'll probably soon get used by libata to manage passworded disks (and thus passworded compact flash) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
On Tue, 2007-08-28 at 19:08 -0400, Havoc Pennington wrote: > A better approach, for example, would be to have selinux or signatures > or something such that apps that come with the OS are automatically > trusted and the dialog or other obscure procedure only arises for > third-party apps. Then people don't get as used to just clicking "yes" > all the time and _might_ slow down for the dialog when it really > matters. Certainly. Maybe add to your spec that there needs to be an easy way for OS vendors / site / system admins to maintain a whitelist of apps that are always allowed to access a certain types of keys without having to nag the user. Means you need a grouping/type concept though. (And FWIW I think path-based security is more than sufficient here.) David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Documents on the Online Desktop
A quick thought about the Online Desktop effort. I've started using the spreadsheets and documents of Google Docs lately and it has really started to change the way I think about documents. The elegant simplicity of the revision management and collaboration of editing a Google Document with a group makes forwarding around variations of a Word document (or even an ODF doc) seem ridiculous. There are a few things I like about Google Documents that I think could be important for the free desktop. 1. Collaboration - the collaboration in Gobby and coming to AbiWord are nice (and real-time), but you still have to find each-other. A google doc just lives on the network. It doesn't have a "home" (beyond a primary account). Everyone invited has equally easy access to it. 2. Organization - rather than a fixed desktop metaphor with a set of folders (which I had been quite satisfied with until now), Google Docs organizes your documents more like email (or Gmail, I suppose) with the most recently edited/created docs at the top of the list. You can order by any other attribute as well. Documents that you're working on are always there at the top, and old stuff just falls away. I'd love it if the documents I work on on my own desktop worked this way as well. Right now, the six-month-old document on my desktop looks exactly the same as the one next to it that I created 10 minutes ago, yet they are not equal. 3. Accessibility - like my IMAP/web-based email, like my jabber accounts, like my whatever-space/book account, the docs I create, share, and edit with Google Documents are accessible from any computer with a web-browser. Given the level of connectivity we enjoy these days, it's surprising that this level of universal access to all of the information on our PCs isn't considered a basic necessity. Of course, there are drawbacks. Google Docs is great for editing documents with limited formatting (though I wouldn't hesitate to write a book using it, and format later - especially given the export options to ODF). WYSIWYG editing can still be pretty annoying on the web and still isn't as solid as most desktop apps. Also, and perhaps most importantly, it's not running on free software. Well, it's running on a lot of free software (*nix, apache, etc.), but the document sharing software itself is not free. This leads towards the discussion of what "free-as-in-speech services" are, and I'm really not sure. One one hand, Google has a good API, good import/export (including free/open formats like ODF), so I can get my data in and out without too much fear of lock-in. On the other hand, I don't have control over a key layer and important aspects of the interface. If Google Docs isn't available in my language, there's nothing I can do. If Google Docs shared my docs with my oppressive government (I'm not suggesting they do, just a hypothetical), there's nothing I can do. Building free-software alternatives to Google Docs seems like a huge undertaking (to do as well as they have done), but I would have said the same thing about a desktop operating system 15 years ago. Anyhow, I don't have any grand conclusions. Rather, I just wanted to share some of the impact the use of Google Documents has had on how I think about documents and the network. If I was to take anything from this, it would be that I don't want the wall to exist between my "desktop documents" that I have created and edited on my own PC (with OpenOffice, Inkscape, etc.) to be completely segregated from any docs I create with an online service. I'm not sure how, but it seems that a document I create on my desktop should show up in my google docs and vice-versa. Cheers, Steven Garrity ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Documents on the Online Desktop
Hi, On 8/28/07, Steven Garrity <[EMAIL PROTECTED]> wrote: > 2. Organization - rather than a fixed desktop metaphor with a set of > folders (which I had been quite satisfied with until now), Google Docs > organizes your documents more like email (or Gmail, I suppose) with the > most recently edited/created docs at the top of the list. Yes! Interestingly, this is similar to the "journal" idea that One Laptop Per Child uses. It's so much better than screwing with folders. (I noticed that I use my desktop background as a lame "journal," since saved files accumulate in order.) > If I was to take anything from this, it would be that I don't want the > wall to exist between my "desktop documents" that I have created and > edited on my own PC (with OpenOffice, Inkscape, etc.) to be completely > segregated from any docs I create with an online service. I'm not sure > how, but it seems that a document I create on my desktop should show up > in my google docs and vice-versa. Yes again! I have looked at this in fact. There are two approaches that both don't work. Approach one would be to get the feed of documents from Google, and merge them with local docs and display all of the documents locally or at your online.gnome.org account. Fatal flaw in approach one is that Google has no API to get the documents, only to get the spreadsheets. Approach two would be to upload documents to google, and the fatal flaw is they have no API for that. We can't fix this since the google stuff isn't open source, but maybe they will address one or both issues eventually. For me if I could get PDFs merged with my google docs that would pretty much cover it, I don't have anything else ever. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requesting UI Freeze break for gnome-panel and gnome-utils
On 8/28/07, Elijah Newren <[EMAIL PROTECTED]> wrote: > On 8/27/07, Shaun McCance <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-08-27 at 23:39 +0200, Vincent Untz wrote: > > > Le lundi 27 août 2007, à 23:09 +0200, Jaap Haitsma a écrit : > > > > Hi, > > > > > > > > The gnome-searchtool icon got removed from gnome-icon-theme because it > > > > got replaced by the system-search icon. > > > > > > > > I've made patches for gnome-searchtool and gnome-panel to use the new > > > > icon. > > > > > > > > http://bugzilla.gnome.org/show_bug.cgi?id=470194 gnome-panel > > > > http://bugzilla.gnome.org/show_bug.cgi?id=470196 gnome-searchtool > > > > > > > > Can I apply the two patches? > > > Clearly, something has to be done. I suppose our options are: > > > > 1) Just make the icon change > > 2) Put the old icons back somewhere > > > I say we make the change. > > Due to Shaun being behind it and his reasoning, here's another > approval to go with Vincent's to give you 2 of 2 approvals. > FYI I just committed the patches of the two bugs listed above Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
