Reminder End of Survey: Relevance of Configuration Systems in Free and Open Source Software
I would like to gently remind anyone interested that the survey will be closed on 18.07.2016. As stated in the previous mailing we are interested in the experience and opinion of people involved in both FLOSS and configuration systems. This includes developers who use or have used configuration related artefacts in their contributions. e.g. also accessing and using environment variables for configuration. http://elektra.limequery.org/625192 As concern of my credibility where raised on two mailing lists I would like to be clearer in this regard. For concerns regarding using a gmail address: I barely use my university email, only when explicitly needed. Why? Because it is a temporary mail address. Once I finished my studies it will be deactivated. Also I use my gmail address for contributions. If you still have any concerns feel free to contact me at e1026292 at tuwien ac at or check my github profile https://github.com/sirblackheart. As for concerns regarding the Elektra Initiative itself you can see its members at https://github.com/ElektraInitiative. In addition you can see offered thesis at http://www.complang.tuwien.ac.at/cgi-bin/uncgi.cgi/prak_dipl1.cgi?kw=Compiler&kw=Constraint+Logic+Programming&kw=Forth&kw=Implementierung+logischer+Programmiersprachen&kw=Java&kw=Linux&kw=Logikprogrammierung&kw=Objektorientierte+Programmiersprachen&kw=Verteilte+Systeme&kw=_Sonstiges&betreuer=raab&type=egal We also hold regular meetings. If you are living near Vienna and are interested in the topic of configuration systems in FLOSS, feel free to contact us to be added to the mailing list. best regards, Gabriel Rauter -- Forwarded message -- From: Gabriel Rauter Date: 2016-06-14 20:41 GMT+02:00 Subject: Survey: Relevance of Configuration Systems in Free and Open Source Software To: kde-devel@kde.org Dear developers, contributors and caretakers of free and open source software. If you are involved in the development of free and open source software (FLOSS) you are the person we are looking for. It would be a great help if you take this survey: http://elektra.limequery.org/625192 It will be available till 18.07.2016 (anywhere on earth). For every thoroughly and not anonymously finished survey € 40 cent will be donated to one of the following organizations of your choice: For every thoroughly and not anonymously finished survey € 40 (at least € 200 in total) cent will be donated. The donation goes to one organisation of your choice. You need to enter your e-mail address to participate. Then you can select between following projects: - LimeSurvey (LimeService, kindly hosts this survey) - SPI (General Donation: 0 A.D., LibreOffice, Debian, ArchLinux, …) - FSFE - GNOME - KDE - Mozilla (Firefox) - Wikimedia Foundation (Wikipedia) So if you know anyone suited for this survey please feel free to share it. As part of the ongoing research on the topic of configuration systems in free and open source software here at Vienna University of Technology, we would like to invite you to participate in this short survey. It should only take you 15 minutes, promised! By supporting us through this survey, you help the research by providing relevant input on this topic. In addition the anonymised results will be released under an open licence, so other projects with involvement in configuration in free and open source software can benefit from it too. In addition the results will be anonymised and made freely available. Just leave your address at the end of the survey and we will send it to you. For further questions regarding this survey or interest in the research of configuration systems feel free to contact as atsur...@libelektra.org. If you have not done it yet, we would appreciate if you take our survey at http://elektra.limequery.org/625192 before the 18.07.2016.
Re: The situation of KWallet, and what to do about it?
On 07.07.2016 18:43, Elvis Angelaccio wrote: - We make encrypted password storage optional and non-default (easiest solution, but not exactly in line with KDE's vision) I disagree on this point. Even if KWallet were free of usability issues, it would still provide a false sense of security. The user thinks that his/her passwords are safe, while in fact they are not. If we don't have enough manpower to develop and mantain a proper keychain in Plasma, we should tell our users. This way they can make sure that, for example, the unsafely stored Wi-Fi passphrase is not used for other accounts. This is already closer to our vision than the current situation. My vote is: we either do it right, or we give up. If someone steps up to fix this problem, great. Otherwise we should start to slowly port away from KWallet. Good point! I still hope we'd find a secure solution, but no central storage may indeed be better than an insecure one.
Re: The situation of KWallet, and what to do about it?
Am 11.07.2016 um 21:27 schrieb Thomas Pfeiffer: On 07.07.2016 18:43, Elvis Angelaccio wrote: - We make encrypted password storage optional and non-default (easiest solution, but not exactly in line with KDE's vision) I disagree on this point. Even if KWallet were free of usability issues, it would still provide a false sense of security. The user thinks that his/her passwords are safe, while in fact they are not. If we don't have enough manpower to develop and mantain a proper keychain in Plasma, we should tell our users. This way they can make sure that, for example, the unsafely stored Wi-Fi passphrase is not used for other accounts. This is already closer to our vision than the current situation. My vote is: we either do it right, or we give up. If someone steps up to fix this problem, great. Otherwise we should start to slowly port away from KWallet. Good point! I still hope we'd find a secure solution, but no central storage may indeed be better than an insecure one no it's not the alternative would be a passwords.txt on the desktop of many users with no autoclose or insecure passwords at all to remember them hardly an improvement signature.asc Description: OpenPGP digital signature
Re: The situation of KWallet, and what to do about it?
On 07.07.2016 19:50, Kevin Ottens wrote: There's two sides to that problem in fact, use from applications and the service provided by our workspace. I think that for applications the answer is neither KSecretService nor KWallet, etc. For the goal of making it easier for our applications to be shipped on more platforms, what we want in fact is to port them away from anything platform specific to something like QtKeyChain: https://inqlude.org/libraries/qtkeychain.html This way, the actual storage becomes a workspace decision. That could keep being KWallet if improved, or KSecretService, or a simple D-Bus service wrapping libsecret... For sure it would at least simplify things on the KWallet/KSecretService side, they wouldn't need to be frameworks anymore (QtKeyChain or equivalent would play that role) just to expose a D-Bus API (likely the Secret Service one in the end). Oh, indeed, that would absolutely make sense! Deploying and using applications which use KWallet outside of Plasma must be a pain right now. So how do we make that happen? Deprecate the KWallet framework and recommend to use QtKeyChain instead, and then in parallel decide which bakcend to use for QtKeyChain in Plasma? https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-> api-0.1.html 0.1 being outdated, you probably want to link that one: https://standards.freedesktop.org/secret-service/ Ah yes, indeed. Hope that somewhat made sense and helps. It made sense to me at least :)
Re: The situation of KWallet, and what to do about it?
Hello, On Monday, 11 July 2016 21:58:34 CEST Thomas Pfeiffer wrote: > On 07.07.2016 19:50, Kevin Ottens wrote: > > There's two sides to that problem in fact, use from applications and the > > service provided by our workspace. > > > > I think that for applications the answer is neither KSecretService nor > > KWallet, etc. For the goal of making it easier for our applications to be > > shipped on more platforms, what we want in fact is to port them away from > > anything platform specific to something like QtKeyChain: > > https://inqlude.org/libraries/qtkeychain.html > > > > This way, the actual storage becomes a workspace decision. That could keep > > being KWallet if improved, or KSecretService, or a simple D-Bus service > > wrapping libsecret... For sure it would at least simplify things on the > > KWallet/KSecretService side, they wouldn't need to be frameworks anymore > > (QtKeyChain or equivalent would play that role) just to expose a D-Bus API > > (likely the Secret Service one in the end). > > Oh, indeed, that would absolutely make sense! Deploying and using > applications which use KWallet outside of Plasma must be a pain right now. Never tried, but I'd suspect it is indeed. > So how do we make that happen? Deprecate the KWallet framework and recommend > to use QtKeyChain instead, and then in parallel decide which bakcend to use > for QtKeyChain in Plasma? Probably something like that yes. Note that I'm not sure how active the QtKeyChain project is right now, so that might be something to evaluate I guess. > >> https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secre > >> ts-> api-0.1.html> > > 0.1 being outdated, you probably want to link that one: > > https://standards.freedesktop.org/secret-service/ > > Ah yes, indeed. > > > Hope that somewhat made sense and helps. > > It made sense to me at least :) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: The situation of KWallet, and what to do about it?
On Mon, Jul 11, 2016 at 9:58 PM, Thomas Pfeiffer wrote: > On 07.07.2016 19:50, Kevin Ottens wrote: > >> There's two sides to that problem in fact, use from applications and the >> service provided by our workspace. >> >> I think that for applications the answer is neither KSecretService nor >> KWallet, etc. For the goal of making it easier for our applications to be >> shipped on more platforms, what we want in fact is to port them away from >> anything platform specific to something like QtKeyChain: >> https://inqlude.org/libraries/qtkeychain.html >> > > This way, the actual storage becomes a workspace decision. That could keep >> being KWallet if improved, or KSecretService, or a simple D-Bus service >> wrapping libsecret... For sure it would at least simplify things on the >> KWallet/KSecretService side, they wouldn't need to be frameworks anymore >> (QtKeyChain or equivalent would play that role) just to expose a D-Bus API >> (likely the Secret Service one in the end). >> > > Oh, indeed, that would absolutely make sense! Deploying and using > applications which use KWallet outside of Plasma must be a pain right now. > > So how do we make that happen? Deprecate the KWallet framework and > recommend to use QtKeyChain instead, and then in parallel decide which > bakcend to use for QtKeyChain in Plasma? I don't get that. How is deprecating KWallet paves the way to make something new with QtKeyChain? As far as i can tell, QtKeyChain isn't a keychain at all, it's a wrapper around platform specific keychains that provides a unified interface for keychain functionality. It itself doesn't implement a keychain (or it does on windows?). Or do you mean deprecating/removing the *graphical* KWallet part and re-implementing that in top of QtKeyChain? Using QtKeyChain would be interesting imho. Specially if that itself is extended to use other web backends as keychain. > > > >>> https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-> >>> api-0.1.html >>> >> >> 0.1 being outdated, you probably want to link that one: >> https://standards.freedesktop.org/secret-service/ >> > > Ah yes, indeed. > > Hope that somewhat made sense and helps. >> > > It made sense to me at least :) > > ___ > Plasma-devel mailing list > plasma-de...@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel >
Re: The situation of KWallet, and what to do about it?
On 2016-07-07, Kevin Ottens wrote: > There's two sides to that problem in fact, use from applications and the=20 > service provided by our workspace. One issue that I'm a bit puzzled about is the following scenario: A user uses KMail for emails. But switches between various desktop environments. Would he need to configure KMail in all of them? /Sune
Re: The situation of KWallet, and what to do about it?
Hello, On Monday, 11 July 2016 20:51:43 CEST Sune Vuorela wrote: > On 2016-07-07, Kevin Ottens wrote: > > There's two sides to that problem in fact, use from applications and > > the=20 > > service provided by our workspace. > > One issue that I'm a bit puzzled about is the following scenario: > > A user uses KMail for emails. > But switches between various desktop environments. > > Would he need to configure KMail in all of them? Depends how much effort we want to put into something like that really. Worst case scenario: he'd have to retype passwords in the various desktop environments. Best case scenario we magically find out that it'd find more passwords with a different backend and so nothing to retype. Personally, I'd put no effort in dealing with that. I have two reasons for that: 1) I don't think many users do that or should do that. Nowadays, most perceive the workspace as part of the OS stack. 2) On Linux, I'd expect those things to converge at one point (could be years of course[*]) and you'd have only one of the potential storages picked by the distro at installation, all the apps would use that one, whatever workspace you're running (talking about something I witnessed, I think it will be a bit like what happened with hardware detection: everyone has a wrongly designed solution, then hal emerged, then udisks and friends, everyone use those now). Regards. [*} But whatever solution we pick forward it'll take months to get there and be used by all our applications anyway. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: The situation of KWallet, and what to do about it?
On Mon, July 11, 2016 21:27:54 Thomas Pfeiffer wrote: > On 07.07.2016 18:43, Elvis Angelaccio wrote: > >> - We make encrypted password storage optional and non-default (easiest > >> solution, but not exactly in line with KDE's vision) > > > > I disagree on this point. Even if KWallet were free of usability > > issues, it would still provide a false sense of security. The user > > thinks that his/her passwords are safe, while in fact they are not. > > If we don't have enough manpower to develop and mantain a proper > > keychain in Plasma, we should tell our users. This way they can make > > sure that, for example, the unsafely stored Wi-Fi passphrase is not > > used for other accounts. This is already closer to our vision than the > > current situation. > > > > My vote is: we either do it right, or we give up. If someone steps up > > to fix this problem, great. Otherwise we should start to slowly port > > away from KWallet. > > Good point! > I still hope we'd find a secure solution, but no central storage may > indeed be better than an insecure one. I strongly agree with the Reindl's reply... abdicating responsibility because we can't do it to the level of perfection required to claim security may be satisfying, but leaving the task to our users to handle alone would be even less secure. What we shouldn't do is offer a "secure" solution that we think isn't secure -- we need to advertise what we think we can deliver and allow our users to make informed decisions from there. We already deliver something better than "passwords.txt", and that solution makes it feasible to avoid password sharing across web sites, which is one of the big problems we face today. Regards, - Michael Pyne
