Top «Prev(2010-01-11) Latest Next(2010-01-19)» Edit

pterjan's diary


2010-01-18

  Mandriva Another update on Mandriva main rebuild

This time it only needed 36 hours instead of 42, maybe because openoffice.org failed :)

So, this week we got 86 failures out of 2927 packages, 1 failure to recreate src.rpm, 18 failure to install build dependencies and 67 failures during build. That's improvement, at last :)

I should stop posting this and work on making things more automated and sending emails to maintainers, but I will probably not work on this soon before a few weeks.

And actually this post is a good opportunity to advertise my nice photo of the week :)

De l'autre cot�

  GNOME Scary keyring dialog

When starting Evolution I now get this dialog:
Capture-Unlock Keyring

Do you really expect me to enter my password because an unknown application popups this dialog ?

First it means people will give access to their keyring to any app, including any virus. But probably also give the password if some code uses /usr/share/gnome-keyring/ui/gkd-prompt.ui to ask for it...

It really scares me...

Today's TSUKKOMI(Total: 15) [Add a TSUKKOMI]
  Götz Waschk (2010-01-18 12:44)

Some of the failures are no failure at all:<br>http://kenobi.mandriva.com/~pterjan/iurt/cooker/i586/main/log/polkit-0.95-1mdv2010.1.src.rpm/

  Pascal (2010-01-18 13:33)

Yes this has happened for filezilla and polkit, I don't know why, I will try to debug iurt

  FACORAT Fabrice (2010-01-18 20:56)

That's why I'm using kwallet without password :)

  Sean (2010-01-19 01:07)

This is one of the areas where Windows security has been lightyears ahead of X/GNOME for at least a decade. There is no secure-key-combo that is guaranteed to show a system screen or verify that the current window is owned by a secure daemon.<br><br>I also absolutely hate the way that the GNOME developers are still putting APIs for applications to handle passwords in libraries like gvfs instead of calling out to things like gnome-keyring directly. Even if you do trust the dialog, the password still ends up passing through the application's hands. Dumb.

  James Henstridge (2010-01-19 01:48)

You can probably get rid of that by deleting ~/.gnome2/keyrings/default.keyring.<br><br>Assuming you're using pam_gnome_keyring, then all your secrets are in login.keyring, with the default.keyring having been created before the PAM module was used.<br><br>The program you're running is likely searching for a secret without specifying a keyring and you don't happen to have the secret in the login keyring, so it tries to unlock the default keyring to see if it exists there.<br><br>I agree that it is a usability/security wart. We've run into it too for some things on Ubuntu.

  Anders (2010-01-19 06:48)

Would you be more comfortable if the virus author wrote some application name in the dialog?

  Pascal (2010-01-19 08:29)

Anders: Not really, but at least I would know if it makes sense for that application to request it at that time

  Hub (2010-01-19 09:56)

The problem of applications prompting password is that it is hard (to not say impossible) for the user to know if this is legitimate or not. When you look how easy it is to phish with fake website and fake certs, then imagine a fake dialog in a fake app?<br><br>And now OS has the solution.

  Stefan Kost (2010-01-19 10:56)

I wish the dialog would at least tell which application ask for it. Also having some shortcuts to help to get the setup working to unlock it at startup, would be nice.

  Stoffe (2010-01-19 15:10)

Another fantastic thing about that popup is that it's not supposed to come up for the regular login as it is tied to the account, but if you set your desktop to login automatically so you don't have to type a password, boom comes this password prompt instead. Facepalm and exit left.

  peder (2010-01-19 22:20)

I have to agree that this is a *huge* security problem that GNOME has to get rid of immediately.

  hehe (2010-01-21 00:30)

@Stoffe , lol lol lol USABILITY FAIL

  xake (2010-01-22 13:21)

How much of a security-problem is this really?<br>For me this dialog comes when something in my login-path has failed (unlike a good distribution should) to unlock my keyring. The keyring needs to be unlocked for the keyring-manager to know if the application is allowed to fetch passwords from the keyring (since that info is also encrypted, you do not want program/people to be able to edit this in clear text) and if the application has not been allowed access before, it asks me if I will allow this access once, for ever or not at all. So this is not a security fail afaics, just a distributor-fail. The applications is never able to read the password you type, the application is not able to fetch a password (unless it was the application to place the password into the keyring or you have granted it access to that key in the keyring).<br><br>Ok, the text could be better so this was somewhat clearer, but please stop the security-FUD.

  Pascal (2010-01-22 13:33)

xake: this happened to me everytime because evolution seems to fail to store the password: (evolution:2206): e-data-server-ui-WARNING **: Unable to create password in keyring (Keyring reports: Programmer error: The application sent invalid data.)<br>So it looked in "default" keyring which was not unlocked (and was last used several years ago and locked with a password it had requested me to enter then, at a time when it was not unlocked on session opening)<br><br>That's not the point, if people has to believe that this dialog is normal and enter their password there, they will if any application display them this dialog by loading gkd-prompt.ui (it takes a few lines to do it).

  Glatz Sonnenschirme (2010-03-09 22:47)

You're absolutely<br>right!


2004|06|07|08|09|11|
2005|01|02|05|06|07|08|09|10|11|12|
2006|01|02|03|06|08|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|12|
2011|02|04|06|
2012|01|05|11|
2013|01|02|04|06|
2014|02|
2015|06|
2017|05|07|12|