Re: [MeeGo-dev] signon-qt: ABI/ABI break
On 12/08/2010 10:08 AM, ext Patrick Ohly wrote: Note that the soname of signon-qt wasn't changed, so my executable continued to run. I would have preferred to get a "libsignon-qt.so.1 not found" error. I was expecting this change to happen and knew what to look for, but others might spend more time debugging this... Thanks for the heads up. I should have done that, indeed. I can no longer verify it (old files gone), but it seems that the database layout in .signon also changed, which removed all of my stored credentials. Alberto, is that possible? It's not a big deal at this point, but once signon really holds end-user data, a better upgrade path would be useful. Yes. Writing queries to migrate to the new DB format seemed to be overkill now, when we are not aware of anyone using our storage in MeeGo. But this version introduces a way to track DB versions and have some code run when upgrading. So hopefully this won't happen anymore. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARM RunFast by default in glibc
On 01/14/2011 11:21 AM, Carsten Munk wrote: 2011/1/14: Enabling run-fast mode using -ffast-math is not-trivial hack. Also required updating packages for compilation flags or global options. Patching glibc is much cheaper to implement and safer. In ideal case the speedup on cotext-a8 could be around 40% (depends on vector/matrix size), even non-vector operations with floats improves for margin more 10%. BUT all float/doubles operations could be are affected: you may get different outcome in comparison to IEEE mode. Got any good benchmarks/tools we can run so we can verify this on actual MeeGo hardfp? http://maemo.org/community/maemo-developers/read/7abdcfc62c7411df94ad0b89e3fcd53dd53d/ and http://maemo.org/community/maemo-developers/read/4af8d4302d2711dfbc6cdfe470c00a6b0a6b/ Not a real benchmark, but it might give an idea. It's about computing the length of a path given its nodes in geocoordinates, on the N900. HTH, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Using meego-dev for the Accounts & SSO project
Hi all, I'd like to hear your comments about the possibility of moving the development team discussions from an internal (and not public) Nokia mailing list to meego-dev. I would estimate the traffic to be from 1 to 5 messages per day (with some occasional spikes, of course) and being mostly consisting of patches and review comments. Reasons for moving away from the internal mailing list should be quite obvious. :-) Accounts & SSO is part of MeeGo Core, yet almost nobody knows about it, and very little contributions are coming from outside of Nokia. I initially though that a project specific ML would be more appropriate (and filed BMC#14801 about that), but if people here don't mind a little extra traffic then having the development happening in this ML would be all fine to me, and could be even more beneficial to the project. You opinion about this proposal is appreciated and, in fact, needed. :-) Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Using meego-dev for the Accounts & SSO project
On 03/25/2011 09:52 AM, Rob Staudinger wrote: On Fri, 2011-03-25 at 09:10 +0200, Alberto Mardegan wrote: I would estimate the traffic to be from 1 to 5 messages per day (with some occasional spikes, of course) and being mostly consisting of patches and review comments. I would encourage you to do patch review in bugzilla primarily, and tie in the mailing list only if there's need to. Yes, I'm aware that the contribution guidelines say that a patch needs to go onto the ML first. Since our code is in gitorious.org, we generally do code reviews in gitorious.org, and we just post a URL to a short comment to the mailing list. Trivial/short patches are usually sent to the mailing list. I think it will be challenging enough to convince all the stakeholder to migrate to a different ML; I wouldn't like to also change the review process. But that said, if someone submits patches as bugzilla attachments, it's also fine to review them there. But to ensure that all team members have a chance to view the submissions, I'd rather encourage using the ML. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-packaging] [meego-commits] 15232 accepted: Trunk:Testing/qmf
Hi, On 03/26/2011 10:00 PM, Arjan van de Ven wrote: > On 3/25/2011 2:28 PM, fathi.bou...@nokia.com wrote: >> I looked deeper into this QMF promotion. Until now,we (MeeGo) used a >> modified version that includes libaccount/libsignon integration. > > this was done properly as the upstream tarbal + patch, right? > (if not, this is very obviously an improvement, to at least not use a > contaminated tarbal) I know that MeeGo QMF has its own repository in gitorious ([0]), but then I don't know how the packaging works (adding Vitaly in CC). > not using libaccount/libsignon would be in the real of the architecture > team obviously. > will get back on that. Hopefully you'll come back with some proposal/discussion, and not a decision? >> 2. Why use an older QMF upstream version? (and introduce epoch) > > using the latest upstream version would be totally fair game. > As to the why the package went away from a contaminated frankenthing to > a clean upstream one... that not only sounds > like a good idea, it actually is. there were many issues with the > frankenpackage, while the upstream one, which is very much > better maintained, fixes lots of these. The only one I'm aware of is BMC#11361. The biggest problem I can see with these Nokia-maintained packages (MeeGo QMF, Accounts&SSO and probably others) is that their development teams are mainly active on the Nokia product-driven developments, and very little time is allocated for the public MeeGo packages. Luckily, at least for Accounts&SSO, this is going to change starting from tomorrow. :-) Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-packaging] [meego-commits] 15232 accepted: Trunk:Testing/qmf
On 03/27/2011 07:06 PM, John Veness wrote: > On 27/03/11 09:59, Alberto Mardegan wrote: >> Luckily, at least for Accounts&SSO, this is going to change starting >> from tomorrow. :-) > > Interesting. What is happening tomorrow? Since tomorrow I have some time allocated to work on meego.com. Concretely, this means that I'll take care of pushing our packages to OBS (it was done till 11th of february, then the resources allocated to this task were assigned to do something else), follow our bugzilla and make sure that all development happens in the open. In other words, trying to be good citizens. :-) Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-packaging] [meego-commits] 15232 accepted: Trunk:Testing/qmf
On 03/27/2011 04:57 PM, Arjan van de Ven wrote: > which indeed, for the packages where this is true, is a huge problem. > the result is that the state of some of these in MeeGo is very poor... > and that leaves/left the architects no choice but to design them out. Then I would expect to see some evidence of this in bugzilla, or some unanswered or poorly answered messages of complaint in the mailing lists. >> Luckily, at least for Accounts&SSO, this is going to change starting >> from tomorrow. :-) > > tomorrow might be too late for several of these however. I just hope that architectural decisions are being taken according to the current state of a project and the developers' commitment on supporting it, and not according to a project's affiliation to Nokia. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Using meego-dev for the Accounts & SSO project
On 03/29/2011 02:05 AM, Ryan Ware wrote: On 03/25/2011 12:33 AM, Michael Przybilski wrote: Since the code is in gitorious and also the bug-fixes have been done in the MeeGo bugzilla, I think it only makes sense to also have the discussions in public. That said, I'd suggest that it might be better to have this in the MeeGo-security ml instead. If the group feels that MeeGo-Security-Discussion is a better place for this, I don't have a problem with it. I don't think it is. The Accounts part has nothing to do with security, while the SSO part is just a client for the security framework, and can be configured to work without any security functionality (and still be useful). That said, continuing to have these discussions on an internal only mail list is problematic. It does not allow us to discuss the shortcomings and issues with the current Accounts & SSO solution with the people that are developing it. 100% agree. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Accounts] Fixes: NB#204950 - Account::verify and Account::verifyWithTokens() returns TRUE, all the time irrespective of whether Account::sign() called or not.
On 03/30/2011 12:07 PM, Lucian Horga wrote:
diff --git a/libaccounts-glib/ag-account.c b/libaccounts-glib/ag-account.c
index a2354ba..21273a1 100644
--- a/libaccounts-glib/ag-account.c
+++ b/libaccounts-glib/ag-account.c
@@ -41,6 +41,10 @@
#include "ag-service.h"
#include "ag-util.h"
+#ifdef HAVE_AEGISCRYPTO
+ #include
+#endif
+
#include
#define SERVICE_GLOBAL "global"
@@ -303,6 +307,7 @@ ag_account_watch_int (AgAccount *account, gchar *key, gchar
*prefix,
return watch;
}
+#ifdef HAVE_AEGISCRYPTO
static gboolean
got_account_signature (sqlite3_stmt *stmt, AgSignature *sgn)
{
@@ -311,6 +316,7 @@ got_account_signature (sqlite3_stmt *stmt, AgSignature *sgn)
return TRUE;
}
+#endif
static gboolean
got_account_setting (sqlite3_stmt *stmt, GHashTable *settings)
@@ -2085,6 +2091,7 @@ ag_account_store_blocking (AgAccount *account, GError
**error)
return TRUE;
}
+#ifdef HAVE_AEGISCRYPTO
static gboolean
store_data (gpointer key, gpointer value, gpointer data)
{
@@ -2169,6 +2176,8 @@ signature_data (AgAccount *account, const gchar *key)
return g_string_free (data, FALSE);
}
+#endif
+
/**
* ag_account_sign:
* @key: the name of the key or prefix of the keys to be signed.
@@ -2179,10 +2188,13 @@ signature_data (AgAccount *account, const gchar *key)
void
ag_account_sign (AgAccount *account, const gchar *key, const gchar *token)
{
+#ifdef HAVE_AEGISCRYPTO
AgSignature *sgn;
AgAccountPrivate *priv;
AgServiceChanges *sc;
gchar *data;
+struct aegis_signature_t signed_data;
+gchar *signed_raw_data;
g_return_if_fail (key != NULL);
g_return_if_fail (token != NULL);
@@ -2192,17 +2204,34 @@ ag_account_sign (AgAccount *account, const gchar *key,
const gchar *token)
g_return_if_fail (data != NULL);
-/* TODO: sign data with token - depends on libmaemosec */
+aegis_crypto_result result_sign =
+ aegis_crypto_sign (data,
+ strlen (data) + 1,
+ token,
+ &signed_data);
signed_data -> signature
Do you have some reason to add 1 to the string length?
-priv = account->priv;
-sc = account_service_changes_get (priv, priv->service, TRUE);
+aegis_crypto_finish ();
Don't call aegis_crypto_finish() here, you are using more agis-crypto function
just below.
+g_free (data);
+g_return_if_fail (result_sign != aegis_crypto_ok);
+
+aegis_crypto_signature_to_string (&signed_data,
+ aegis_as_base64,
+ token,
+ &signed_raw_data);
signed_raw_data -> signature_string
sgn = g_slice_new (AgSignature);
-sgn->signature = data; //signed_data;
+sgn->signature = g_strdup (signed_raw_data); //signed_data;
remove the comment, it's obsolete now.
+g_free (signed_raw_data);
sgn->token = g_strdup (token);
+priv = account->priv;
+sc = account_service_changes_get (priv, priv->service, TRUE);
+
g_hash_table_insert (sc->signatures,
g_strdup (key), sgn);
+#else
+g_warning ("ag_account_sign: aegis-crypto not found! Unable to sign the
key.");
+#endif
}
/**
@@ -2219,13 +2248,20 @@ ag_account_sign (AgAccount *account, const gchar *key,
const gchar *token)
gboolean
ag_account_verify (AgAccount *account, const gchar *key, const gchar **token)
{
+#ifdef HAVE_AEGISCRYPTO
AgAccountPrivate *priv;
AgServiceSettings *ss;
guint service_id;
gchar *data;
gchar *sql;
AgSignature sgn;
-
+GString *sql_str;
+aegis_system_mode_t made_in_mode;
+aegis_crypto_result result_verify;
+aegis_crypto_result result_convert;
+struct aegis_signature_t signature;
+char *token_name;
+
g_return_val_if_fail (AG_IS_ACCOUNT (account), FALSE);
priv = account->priv;
@@ -2235,7 +2271,7 @@ ag_account_verify (AgAccount *account, const gchar *key,
const gchar **token)
service_id = (priv->service != NULL) ? priv->service->id : 0;
-GString *sql_str;
+
sql_str = g_string_sized_new (512);
_ag_string_append_printf (sql_str,
"SELECT signature, token FROM Signatures "
@@ -2246,16 +2282,44 @@ ag_account_verify (AgAccount *account, const gchar
*key, const gchar **token)
(AgQueryCallback)got_account_signature,
&sgn, sql);
-g_free(sql);
-data = signature_data(account, key);
+g_free (sql);
+data = signature_data (account, key);
+
+aegis_crypto_init();
-/* TODO: verify data with sgn->signature - depends on libmaemosec */
+result_convert = aegis_crypto_string_to_signature (sgn.signature,
+&signature,
+&token_name);
+
+if (result_convert != aegis_crypto_ok) {
+*token =
[MeeGo-dev] [SSO][PATCH] Signon: make authentication plugins log to syslog
Hi all, I've written some patches to address the issue described in the subject, and improved a bit the situation concerning the pollution of the TRACE() macros. Please see the last 7 commits in this branch: https://gitorious.org/accounts-sso/signon/commits/debug-cleanup Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] tablet user experience source is now open...
On 03/31/2011 12:16 PM, Sousou, Imad wrote: Today, we've made available the source code for the tablet user experience project. [...] As always, we look forward to your feedback and contributions. Is there a mailing list specifically for this project? Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Accounts] Fixes: NB#204950 - Account::verify and Account::verifyWithTokens() returns TRUE, all the time irrespective of whether Account::sign() called or not.
On 03/31/2011 01:40 PM, ext-lucian.ho...@nokia.com wrote: Do you want the name changed from "signed_data" to "signature" or you want to select the "signature" field from "signed_data"? Just rename. Do you have some reason to add 1 to the string length? I assumed the string to be null-terminated. It is, but I don't see why we should encrypt the terminator as well. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] [SSO][PATCH] Fix installation path of SASL plugin
The authentication plugins should be in /usr/lib/signon/, not in /usr/lib/. See last commit from: https://gitorious.org/accounts-sso/signon/commits/saslplugin Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [PATCH 1/1] Fixes: Bug 204950 - Account::verify and Account::verifyWithTokens() returns TRUE all the time irrespective of whether Account::Account::verify and Account::verifyWithTokens
On 04/01/2011 10:20 AM, Lucian Horga wrote:
+aegis_crypto_signature_to_string (&signature,
+ aegis_as_base64,
+ token,
+&signature_string);
+aegis_crypto_finish ();
sgn = g_slice_new (AgSignature);
-sgn->signature = data; //signed_data;
+sgn->signature = g_strdup (signature_string);
+g_free (signature_string);
signature_string has been allocated by aegis_crypto, so to free it you shouldn't
use g_free, but some other function provided by that library.
@@ -2219,12 +2247,19 @@ ag_account_sign (AgAccount *account, const gchar *key,
const gchar *token)
gboolean
ag_account_verify (AgAccount *account, const gchar *key, const gchar **token)
{
+#ifdef HAVE_AEGISCRYPTO
AgAccountPrivate *priv;
AgServiceSettings *ss;
guint service_id;
gchar *data;
gchar *sql;
AgSignature sgn;
+GString *sql_str;
+aegis_system_mode_t made_in_mode;
+aegis_crypto_result result_verify;
+aegis_crypto_result result_convert;
+struct aegis_signature_t signature;
+char *token_name;
g_return_val_if_fail (AG_IS_ACCOUNT (account), FALSE);
@@ -2235,7 +2270,7 @@ ag_account_verify (AgAccount *account, const gchar *key,
const gchar **token)
service_id = (priv->service != NULL) ? priv->service->id : 0;
-GString *sql_str;
+
sql_str = g_string_sized_new (512);
_ag_string_append_printf (sql_str,
"SELECT signature, token FROM Signatures "
@@ -2246,16 +2281,48 @@ ag_account_verify (AgAccount *account, const gchar
*key, const gchar **token)
[...]
+result_convert = aegis_crypto_string_to_signature (sgn.signature,
+&signature,
+&token_name);
+
+if (result_convert != aegis_crypto_ok) {
+*token = NULL;
+aegis_crypto_finish();
+g_free (data);
+return FALSE;
+}
+
+result_verify = aegis_crypto_verify (&signature,
+ token_name,
+ data,
+ strlen (data),
+&made_in_mode);
+
+if (result_verify != aegis_crypto_ok) {
+*token = NULL;
+aegis_crypto_finish ();
+g_free (data);
+return FALSE;
I just noticed now, that also here you need to free the token_name.
+}
+
+*token = g_strdup (token_name);
+if (token_name)
+ free(token_name);
Again, use a function from aegis_crypto.
Ciao,
Alberto
--
http://blog.mardy.it <-- geek in un lingua international!
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [PATCH 1/1] Fixes: Bug 204950 - Account::verify and Account::verifyWithTokens() returns TRUE all the time irrespective of whether Account::sign() called or not. Modifications according
On 04/04/2011 01:14 PM, Lucian Horga wrote:
@@ -2192,17 +2204,33 @@ ag_account_sign (AgAccount *account, const gchar *key,
const gchar *token)
g_return_if_fail (data != NULL);
-/* TODO: sign data with token - depends on libmaemosec */
+aegis_crypto_result result_sign =
+ aegis_crypto_sign (data,
+ strlen (data),
+ token,
+&signature);
+aegis_crypto_free (data);
Who allocated "data"? I think this should be a g_free().
+token_name = NULL;
+result_convert = aegis_crypto_string_to_signature (sgn.signature,
+&signature,
+&token_name);
-/* TODO: verify data with sgn->signature - depends on libmaemosec */
+if (result_convert != aegis_crypto_ok) {
+*token = NULL;
+aegis_crypto_finish ();
+aegis_crypto_free (data);
Same here: g_free.
+return FALSE;
+}
-g_free (data);
+result_verify = aegis_crypto_verify (&signature,
+ token_name,
+ data,
+ strlen (data),
+&made_in_mode);
+
+if (result_verify != aegis_crypto_ok) {
+*token = NULL;
+aegis_crypto_finish ();
+aegis_crypto_free (data);
g_free, and also free the token_name (I'll let you guess how :-) ).
+return FALSE;
+}
+
+*token = g_strdup (token_name);
+if (token_name)
+ aegis_crypto_free (token_name);
+
+aegis_crypto_finish ();
+aegis_crypto_free (data);
g_free().
Ciao,
Alberto
--
http://blog.mardy.it <-- geek in un lingua international!
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [PATCH 1/1] Fixes: Bug 204950 - Account::verify and Account::verifyWithTokens() returns TRUE all the time irrespective of whether Account::sign() called or not. Modifications according
On 04/07/2011 04:34 PM, Lucian Horga wrote:
On 04/04/2011 01:36 PM, ext Alberto Mardegan wrote:
On 04/04/2011 01:14 PM, Lucian Horga wrote:
Who allocated "data"? I think this should be a g_free().
data = signature_data (account, key);
it's aegis-crypto function who allocates it so g_free() is not ok here.
aegis_crypto_free (data) is fine.
Unless you forgot to send some patch, it doesn't. The version of signature_data
currently in master doesn't use any aegis-crypto functions.
Same here: g_free.
Same here, as above, aegis_crypto_free (data) is ok.
Same here :-)
+ if (result_verify != aegis_crypto_ok) {
+ *token = NULL;
+ aegis_crypto_finish ();
+ aegis_crypto_free (data);
g_free, and also free the token_name (I'll let you guess how :-) ).
token_name is allocated by aegis-crypto:
Yes,
[...]
and it has been freed here at line 2316:
if (token_name)
aegis_crypto_free (token_name);
which will never be executed in this case, because we are returning from the
function 5 lines above this. Please check my review carefully.
g_free().
Same as above, aegis_crypto_free (data) is fine.
Same here. :-)
Ciao,
Alberto
--
http://blog.mardy.it <-- geek in un lingua international!
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Accounts] Fixes: Bug 204950 - Account::verify and Account::verifyWithTokens() returns TRUE all the time irrespective of whether Account::sign() called or not. Modifications according
On 04/08/2011 03:56 PM, ext-lucian.ho...@nokia.com wrote:
+result_verify = aegis_crypto_verify (&signature,
+ token_name,
+ data,
+ strlen (data),
+&made_in_mode);
+
+if (result_verify != aegis_crypto_ok) {
+*token = NULL;
+aegis_crypto_finish ();
+g_free (data);
+aegis_crypto_free (token_name);
+return FALSE;
+}
It's all OK, just swap the order of aegis_crypto_finish() and
aegis_crypto_free() here.
I think you'll also need to make some adjustments to the unit tests now, to make
them run successfully with and without aegis-crypto.
Ciao,
Alberto
--
http://blog.mardy.it <-- geek in un lingua international!
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] [SSO][PATCH] Refactoring of CredentialsAccessManager class
Hi all, I'd like to ask you a pre-review on the following branch: https://gitorious.org/accounts-sso/signon/commits/keymodel (the first commit to review is cd7d90398e6df31096496c6eaacbd287265472aa) I'm saying "pre-review" because the code is totally untested, and I'll be submitting another iteration of the branch with the changes that I'll most likely have to apply to make it work properly. But since this refactoring involves creation of new classes (which will sooner or later be moved to the libsignon-extension API), it's important at least to agree on the naming and APIs of the newly introduced classes: - KeyHandler: this class aggregates information coming from the key managers, and provides a couple of methods for granting and revoking authorization to encryption keys. - AbstractKeyAuthorizer: this class defines the API that will have to be implemented by plugins who wish to change the logic of deciding whether a new key must be added to the cryptsetup configuration. The other added class, UiKeyAuthorizer, is a subclass of AbstractKeyAuthorizer and will eventually be moved into a dynamically loadable plugin. My doubts concern especially the meaning of "authorizing a key", which we have been using in two different contexts: 1) inserting/removing a key into the cryptsetup configuration, so that the key will be usable to mount the encrypted storage; 2) deciding whether the action in (1) has to be taken. The AbstractKeyAuthorizer tries to avoid the confusion by calling its API "queryKeyAuthorization" (and corresponding signal "keyAuthorizationQueried"), but I wonder if we could find different names for these concepts. Maybe we could leave the "authorize" word for the action of deciding on the authorization of the key, and use "trust" to mean that a key is stored into the cryptsetup configuration? Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [SSO][PATCH] Refactoring of CredentialsAccessManager class
On 04/13/2011 12:07 PM, Alberto Mardegan wrote: I'm saying "pre-review" because the code is totally untested, and I'll be submitting another iteration of the branch with the changes that I'll most likely have to apply to make it work properly. Now I've tested the changes and fix a few silly bugs. To ease commenting, I've created a review request: https://gitorious.org/accounts-sso/signon/merge_requests/2 Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] MSSF manifests in RPM
Hi all, what is the current state of MSSF manifest files in MeeGo? In Maemo Harmattan, they are located under the debian/ directory and there are special build rules to add the to the package. What about RPMs? I had a look at the rpm repository [0] (part of the MSSF) and it seems that there is a "%mssf" directive one can specify in the .spec files, but I cannot find any documentation or examples for it. Last but not last, did MSSF v2 make its way into MeeGo 1.2? Ciao, Alberto [0] https://meego.gitorious.org/meego-platform-security/rpm -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MSSF manifests in RPM
(moving thread to meego-architecture) On 05/02/2011 04:53 PM, Arjan van de Ven wrote: On 5/2/2011 5:39 AM, Alberto Mardegan wrote: Hi all, what is the current state of MSSF manifest files in MeeGo? the current state is that MSSF is not part of, or integrated into, MeeGo... and won't be. Mmm... but I think we all agree that a security framework is needed. What will it be, then? In your mail from March 7th, you announced that the long term focus for the MeeGo security would be end-user privacy. To me, that also means having the means for a process which "owns" some of the user data to establish the identity of another process which requests access to the said data. IMHO, this is something that MSSF is doing very well in Harmattan, so I hope that this possibility will also come to MeeGo. Without this, you basically cannot give different access rights to applications which are coming from a trusted origin (such as the device manufacturer or an approved application store) and applications coming from the community. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [SSO] - AuthSession::signedOut() Signal
On 05/09/2011 10:49 AM, Aurel Vasile Popirtac wrote: Hi, Here are 3 patches. Please send them as a merge request. :-) Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?
Hi, On 05/09/2011 01:23 PM, Sakari Poussa wrote: [...] As we know, in the future Qt versions the QtGraphicsView will be deprecated in the favor of SceneGraph. Never heard of this. AFAIK, the scene graph doesn't even exist as an API yet. What's your source? Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [PATCH 1/3] Fixes: NB#Account::verify and Account::verifyWithTokens() returns TRUE all the time irrespective of whether Account::sign() called or not.
On 06/14/2011 11:32 AM, Aurel Popirtac wrote:
---
configure.ac |9
libaccounts-glib/Makefile.am |4 +-
libaccounts-glib/ag-account.c | 107 ++---
tests/check_ag.c | 24 +++--
4 files changed, 118 insertions(+), 26 deletions(-)
diff --git a/configure.ac b/configure.ac
index 913dbb5..ff2300f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -18,6 +18,15 @@ AC_SUBST(LIBACCOUNTS_LIBS)
PKG_CHECK_MODULES([CHECK], [check>= 0.9.4])
+dnl Check for aegis-crypto library.
+PKG_CHECK_MODULES(AEGISCRYPTO, aegis-crypto, have_aegiscrypto=yes)
+
+if test x$have_aegiscrypto = xyes; then
+ AC_DEFINE(HAVE_AEGISCRYPTO, 1, [Description])
Don't use tabs.
+AC_SUBST(AEGISCRYPTO_CFLAGS)
+AC_SUBST(AEGISCRYPTO_LIBS)
+fi
+
AC_ISC_POSIX
AC_PROG_CC
AM_PROG_CC_STDC
diff --git a/libaccounts-glib/Makefile.am b/libaccounts-glib/Makefile.am
index 9056620..f348e7b 100644
--- a/libaccounts-glib/Makefile.am
+++ b/libaccounts-glib/Makefile.am
@@ -1,8 +1,8 @@
lib_LTLIBRARIES = \
libaccounts-glib.la
-libaccounts_glib_la_CFLAGS = $(LIBACCOUNTS_CFLAGS) -Wall -Werror
-libaccounts_glib_la_LIBADD = $(LIBACCOUNTS_LIBS) -lrt
+libaccounts_glib_la_CFLAGS = $(LIBACCOUNTS_CFLAGS) $(AEGISCRYPTO_CFLAGS) -Wall
-Werror
Wrap lines at 80 characters.
+++ b/libaccounts-glib/ag-account.c
@@ -41,6 +41,10 @@
#include "ag-service.h"
#include "ag-util.h"
+#ifdef HAVE_AEGISCRYPTO
+ #include
+#endif
For this to work, you also need to include config.h.
@@ -2192,26 +2207,42 @@ ag_account_sign (AgAccount *account, const gchar *key,
const gchar *token)
g_return_if_fail (data != NULL);
-/* TODO: sign data with token - depends on libmaemosec */
+aegis_crypto_result result_sign =
+aegis_crypto_sign (data,
+ strlen (data),
+ token,
+&signature);
+g_free (data);
+g_return_if_fail (result_sign == aegis_crypto_ok);
-priv = account->priv;
-sc = account_service_changes_get (priv, priv->service, TRUE);
+aegis_crypto_signature_to_string (&signature,
+ aegis_as_base64,
+ token,
+&signature_string);
+aegis_crypto_finish ();
No, you are using aegis_crypto just a few lines below.
sgn = g_slice_new (AgSignature);
-sgn->signature = data; //signed_data;
+sgn->signature = g_strdup (signature_string);
+aegis_crypto_free (signature_string);
sgn->token = g_strdup (token);
[...]
diff --git a/tests/check_ag.c b/tests/check_ag.c
index df02c0d..46de191 100644
--- a/tests/check_ag.c
+++ b/tests/check_ag.c
@@ -1427,11 +1427,11 @@ END_TEST
START_TEST(test_sign_verify_key)
{
-const gchar *key = "test_key/";
const gchar *key1 = "test_key/key1";
const gchar *key2 = "test_key/key2";
-const gchar *list_of_tokens[] = {"t", "tok", "token", NULL};
-const gchar *token = "token";
+const gchar *list_of_tokens[] = {"libaccounts-glib0::t", "libaccounts-glib0::tok",
"libaccounts-glib0::accounts-glib-access", NULL};
Wrap at 80 chars.
@@ -1461,6 +1461,11 @@ START_TEST(test_sign_verify_key)
g_value_unset (&value);
ag_account_store (account, account_store_now_cb, TEST_STRING);
+ok = ag_account_verify (account, key1,&reply_token);
Space after comma (also later).
Ciao,
Alberto
--
http://blog.mardy.it <-- geek in un lingua international!
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [PATCH 1/3] Fixes: NB#Account::verify and Account::verifyWithTokens() returns TRUE all the time irrespective of whether Account::sign() called or not.
On 06/14/2011 02:50 PM, Aurel Popirtac wrote:
@@ -1427,16 +1429,25 @@ END_TEST
START_TEST(test_sign_verify_key)
{
-const gchar *key = "test_key/";
const gchar *key1 = "test_key/key1";
const gchar *key2 = "test_key/key2";
-const gchar *list_of_tokens[] = {"t", "tok", "token", NULL};
-const gchar *token = "token";
+const gchar *list_of_tokens[] = {
+"libaccounts-glib0::dummy",
+"libaccounts-glib0::toodummy",
+"libaccounts-glib0::accounts-glib-access", NULL };
+const gchar *token = "libaccounts-glib0::accounts-glib-access";
+const gchar *reply_token;
const gchar *data = "some value 1";
const gchar *data2 = "some value 2";
gboolean ok;
GValue value = { 0 };
+#ifndef HAVE_AEGISCRYPTO
+g_debug ("test_sign_verify_key: aegis-crypto not detected, skipping.");
+end_test ();
+return;
+#endif
Don't you get a compiler warning when compiling without aegis-crypto?
Anyway, better wrap the whole function between HAVE_AEGISCRYPTO, and not execute
the test when aegis-crypto is not found.
Ciao,
Alberto
--
http://blog.mardy.it <-- geek in un lingua international!
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [PATCH 2/3] Increased timeout for the test_blocking test.
On 06/14/2011 02:50 PM, Aurel Popirtac wrote: --- tests/check_ag.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/tests/check_ag.c b/tests/check_ag.c index a080089..dc5c79f 100644 --- a/tests/check_ag.c +++ b/tests/check_ag.c @@ -1419,9 +1419,13 @@ START_TEST(test_blocking) * * fail_unless (block_ms> timeout_ms - 100); * - * Instead, let's just check that we haven't been locking for too long: + * Instead, let's just check that we haven't been locking for too long. + * + * Note: Increased expected blocking time with 1000 ms ((+ 500) + 1000). + * Investigate whether this is needed because of a fault in the accounts-glib + * system or not! This comment is rather cryptic. Better remove it altogether. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Il 10/03/2011 09:01 AM, Carsten Munk ha scritto: The goal is to find a truly sustainable way for MeeGo and other interested communities to work with Tizen. Our solution is the Mer Project: [...] That's fantastic! I can't make any promises, as "free time" is an obsolete concept for me, but I'll support the project as much as I can. Thanks guys for driving this! Ciao, Alberto ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] New account service API; comments welcome
Hi all,
I hope I won't annoy you too much if I shortly introduce myself. :-)
I'm a developer from the Nokia Accounts&SSO team, which developed the
libaccounts and libsignon components now available in MeeGo core.
Unfortunately so far we have not been active in the MeeGo (and earlier,
Maemo) community, that's why I don't expect many people here to know
what Accounts&SSO is about; but I hope this is going to change, and with
time (and public docs) we'll eventually get to present us better.
The development in the Accounts & SSO (Single Sign On) components is
still mostly driven by Nokia, but the git repositories are open [0] and
we should soon have our bugzilla component.
Now, to the point. Our current APIs in libaccounts-glib and
libaccounts-qt for accessing account service settings could be much
simpler to use than how they are now, so I've sketched some API of a new
AccountService class and I'd like to be informed of any dislike, before
we start implementing it.
For those who don't know the current API: our Account object holds all
the settings for an account; there are some global settings (such as
username, display name) and service-specific settings (for e-mail, IM,
calendar,...) which are all accessible on the same Account object, by
first selecting the service one needs to work with. In pseudo-code, this
shows like this:
// get the username from the global settings
username = account->value("username");
enabled = account->enabled();
// get some e-mail settings
account->selectService(Service("gmail"));
imapServer = account->value("server");
imapPort = account->value("port");
emailEnabled = account->enabled();
// get some IM settings
account->selectService(Service("google-talk"));
jabberServer = account->value("server");
jabberPort = account->value("port");
imEnabled = account->enabled();
This approach carries the risk that if clients forget calling
selectService(), they can easily get wrong data out of the account.
The new proposed classes for libaccounts-glib [1] and libaccounts-qt [2]
aim at solving this, by introducing an AccountService object which
represents an account configuration always selected on the given service:
accountService = new AccountService(account, Service("gmail"));
imapServer = accountService->value("server");
imapPort = accountService->value("port");
// the next line returns true only if the account is enabled *and* the
// "gmail" service is enabled on it
emailEnabled = accountService->enabled();
Feel free to add your comments on the gitorious web interface or here in
the mailing-list.
Ciao,
Alberto
[0] http://gitorious.org/accounts-sso
[1]
http://gitorious.org/accounts-sso/accounts-glib/commit/2f4c9f9f8e0bb822068e959c44cfb493356af9ab
[2]
http://gitorious.org/accounts-sso/accounts-qt/commit/aa8ebd500175e8bc14a195c6119365c2e22c
--
http://blog.mardy.it <- geek in un lingua international!
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] New account service API; comments welcome
Hi Patrick,
On 08/30/2010 12:29 PM, Patrick Ohly wrote:
Despite our (brief) discussions around what Accounts&SSO is (and isn't -
see http://bugs.meego.com/show_bug.cgi?id=5017), I still have the
problem that I haven't used any of the Accounts&SSO APIs and do not
fully understand it. Is there now some design document or component
overview of Accounts&SSO available?
Unfortunately there aren't any available for public yet. I've been told that
they'll be published with the SDK release.
BTW, I've just commented on that feature request you linked above; what you were
asking is exactly the point of SSO. :-)
Can you take a step back and explain how "accounts" are created and
identified? Not relevant for the suggestion below, but for using
Accounts&SSO in general.
Sure. Hopefully I'll have some time to put this information to a wiki, as well
as some architecture document; as this is an OS project, waiting for company's
milestones doesn't seem correct.
I'll stay on topic with this mail, and only talk about the accounts FW; the SSO
part is a bigger beast, but mostly orthogonal to this.
The goal is to have only one account UI for all your accounts; instead of
configuring part of your Google account in Thunderbird (for e-mail), Empathy or
Pidgin (for IM), F-Spot (for photo/video sharing), etc., we'd like to offer the
user the possibility to have all of an account's settings in a single place,
divided by sections specific to every service type.
So, we'd have one section with all the settings that are global for the account:
username, password (although in practice the password will be stored into the
SSO DB, but let's pretend that SSO does not exist and that we are storing the
password in the accounts DB), display name, maybe avatar, and a switch to
enable/disable the account.
Then, every service provided by the account would add its own settings (if any);
for sure there should be a switch to toggle the service on/off, plus any
settings that makes sense for the service. For instance, the image sharing
section could contain a setting for the maximum image resolution to be used when
uploading.
This account UI could be in the control panel of the device, but it could also
offer some IPC so that applications could invoke it for configuring a specific
service type; for instance, e-mail application could have a menu item "Edit
e-mail accounts" which would bring a view of all the accounts providing the
e-mail service, and only the e-mail sections of each account could be shown.
That's about the UI. For applications, it means that all account settings are
stored in a single DB, and the API provided by libaccounts-{glib,qt} allows them
to enumerate the accounts (filtering by enabled accounts, or by service type),
and access the settings stored in each section. So, given a google account, the
account->selectService(Service("gmail")) method could be used to select the
gmail settings and start reading/writing them.
Now I hope that my original e-mail would make more sense. :-)
Ciao,
Alberto
--
http://blog.mardy.it <-- geek in un lingua international!
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] New account service API; comments welcome
Hi Ross, On Fri, Sep 3, 2010 at 11:41 AM, Ross Burton wrote: > One thing I've been meaning to ask is what is the overlap and > differences between libaccounts and the Freedesktop Secrets DBus > specification (as implemented in the latest gnome-keyring and KDE). There is no overlap; libaccounts does not provide secure storage. Secure storage of user secrets is provided by the SSO (Single Sign On) subsystem. I'm trying to find some time to document the basicas about both subsystem in our wiki [0], but I don't promise anything in the short time. The fundamental difference between our SSO and the freedesktop one is that our main goal is to provide authentication methods to application (not all of them, only those who have the necessary rights), and not (only) secure storage of data. Ideally, in our plans, application shouldn't even be required/allowed to obtain the user password in order to perform any task; they would just receive a token (or a series of tokens, to be used for instance as SASL responses) to be used to authenticate to a (remote) service. Extending our SSO APIs to accomodate arbitrary key/value pairs is something we are considering -- at the moment the thing we are storing securely is just a simple string. Ciao, Alberto ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Review board for MeeGo
On 09/14/2010 09:28 AM, Vitaly Repin wrote: BTW, don't forget about gitorious code review feature: http://blog.gitorious.org/2009/11/06/awesome-code-review/ I don't like it for a few reasons: - The code is not showed with a monospaced font, so it's nearly impossible to check the indentation - Inline commenting sometimes does not work: you click on one line number and nothing happens - You only see the diff; reviewboard instead provides a clickable link which expands showing also the unchanged code - I never get any notification when someone adds a comment Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-community] A failed test case of libaccounts-qt
Hi Aska Wu, On 09/24/2010 11:41 AM, aska...@acer.com.tw wrote: It seems to be a mistake of this test case. thanks for spotting the issue and for your patch. As Fathi wrote, you can submit it to gitorious (soon we'll have a bugzilla component, hopefully!). Also please use the meego-dev mailing list for issues regarding the development of components of the MeeGo OS. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] QtLocation MeeGo repository
Hi Juha, On 09/29/2010 06:11 AM, juha.vuo...@nokia.com wrote: I’ve set up a git repository dedicated for developing the positioning component of the QtLocation API for MeeGo platform. Great! I've one question about the API: I think it would make sense to add a void QGeoPositionInfoSource::setLastKnownPosition(const QGeoCoordinate &); method, to initialise the positioning source to a known location. This might help the engine to get the correct location faster. The use-case of this is: last time I had my GPS on, I was in Helsinki. If now I'm in Dublin and switch my GPS on, I could use some map application or widget to pick Dublin as my known location, to get the fix faster. Does it make sense to you? Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] QtLocation MeeGo repository
On 09/29/2010 09:25 PM, Robin Burchell wrote: Excerpts from Alberto Mardegan's message of Wed Sep 29 21:14:14 +0300 2010: Great! I've one question about the API: I think it would make sense to add a void QGeoPositionInfoSource::setLastKnownPosition(const QGeoCoordinate&); [...] Does it really make sense to have this in public API targetted at application developers? I'm not so sure about that... Multiple places all setting it (some of which probably without rigorous QA) could lead to problems all too easily, even if that problem is just longer time to get a fix. This *is* an API for application developers! The user will use it when he knows his approximate location. Of course it doesn't make sense to have this if the framework already provides some UIs which allow the user to pick his estimated position, but I don't think this will be the case. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] QtLocation MeeGo repository
On 09/30/2010 06:00 PM, Andrew Flegg wrote: Nothing stops a QGeoPositionInfoSource from caching the result internally, (as opposed to a ::setLastKnownPosition()). Indeed, but this isn't the use case Alberto's described (BICBW). Exactly. My use case is when the last known position is wrong (another country, for instance). The typical case is when you travel abroad: you don't want to use network-based positioning (either unavailable, or too expensive), and you know your approximate location. I plan to introduce this feature in Mappero for maemo5 -- but still need to check whether it helps at all :-) Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Accounts&SSO: define account and use it for Google Contacts/SyncML
Hi Patrick,
On 10/07/2010 02:09 PM, Patrick Ohly wrote:
There still is confusion around Accounts&SSO and what it does.
Specifically, storing plain text passwords in it is under dispute.
Alberto closed a corresponding feature request in the MeeGo 1.0 time
frame, saying that it works and gave some example code:
http://bugs.meego.com/show_bug.cgi?id=5017
But now Sateesh disagrees and says that "retrieving the credentials is
something that is not officially supported or is going to be removed and
is not going to be supported in
future." (http://bugs.meego.com/show_bug.cgi?id=8027#c4)
Retrieving the plain credentials is something we are discouraging, because of
security reasons.
On the other hand, we are aware that migrating an existing application to use
the SSO authentication methods (and not use the password directly) can take time
and in some cases involve some heavy redesign. For this reasons, we provide a
"password" authentication method that allows the client to directly get the
credentials; this would allow all the client applications to migrate to SSO in a
shorter time, while not forcing them to major architectural changes.
We won't remove the password plugin; even if we did, someone else could easily
write their own authentication plugins which could do the same things. So, this
method is going to stay.
On the other hand, the application which creates the credentials record in the
SSO DB (typically, the accounts UI) can specify the allowed authentication
methods, and that's where the "password" method might be blocked. But it would
be a per-account decision, taken by the account plugin writer and not by the
framework.
We also don't have a UI for it, nor any of the plugins which presumably
are needed for each online account that is meant to show up in
Accounts&SSO. Someone needs to add that sooner or later, but at least I
have no idea how to do that.
So let's discuss one specific example: Google. The same
username/password combination works in the web browser when accessing
pages and in the SyncML server offered by Google for contact access.
There are several open issues. Please correct/amend...
* Define "Google" account. Done by writing a
accounts-provider-plugin. Where is that API defined? How is such
a plugin installed? Is there an example?
The API is defined in libaccounts-ui, which is still stuck in the Nokia internal
legal processes to be open-sourced, we are all waiting. :-/
In some cases the plugin could be just an XML file that describes various
parameters of the account creation process; and actually it will be the very
same file as the libaccounts-{qt,glib} provider files.
In other cases, one might want to write his own plugin as a binary object, which
will be run by the accounts UI when creating/editing an account.
So, typically, the installation package for a provider plugin will consist of an
XML provider file and optionally of a binary executable.
* Define services offered by "Google". Done by writing one or more
accounts-service-plugins. Same as before - API and example? Are
service plugins optional if applications provide different ways
of activating services?
For the first question, same answer as before. :-(
About the second question: service plugins can be written as
libaccounts-qt-glib} XML service file extended with some extra elements needed
by the accounts UI, and if needed they can also by a binary loadable object.
And yes, they are optional. If for example I create my own social web service in
example.com and I don't want it to be integrated with the pre-installed MeeGo
applications and instead I want it to be only usable via my own ExampleApp
application, I don't need to write any service plugins. I would only write an
account provider plugin, if I want the example.com account to be created with
the MeeGo accounts UI; or if I don't even want to have it in the accounts UI but
have it all inside my ExampleApp, then I can avoid writing any plugins at all
(but I can still use libaccounts-{qt,glib} for storage, if I want to).
* Request account credentials. API is libsignon-qt/glib? User
enters them in a dialog opened by signon-ui daemon, they get
verified by accounts-provider-plugin. Are they returned to
requesting app as explained in
http://bugs.meego.com/show_bug.cgi?id=5017#c8 ? Does the
accounts-provider-plugin have to do something for this to work?
No. Notice that account-{provider,service}-plugins are only relevant in the
context of the accounts UI; that is, they are only involved when creating or
editing an account, and not when an account is used.
You probably meant "authentication plugin": this is a plugin for the SSO deamon
(signond). When a client wants to authenticate on an account using the method
, signond loads the signon--plugin (actually now I
don't remember the exact name, but what's impor
Re: [MeeGo-dev] Accounts&SSO: define account and use it for Google Contacts/SyncML
On 10/07/2010 09:24 PM, James Ausmus wrote: * Propagate the A&SSO Google account into Telepathy, including Jabber/XMPP-specific account settings (also, how would these Telepathy/Telepathy-connection-manager/protocol-specific settings be exposed to the user for configuration?) This is mostly done. Telepathy MC (mission-control) already contains code to read accounts from the accounts DB: http://git.collabora.co.uk/?p=telepathy-mission-control.git;a=blob;f=src/mcd-account-manager-sso.c; Also, a telepathy channel handler for SASL authentication via SSO is in the works, and I hope it will be open source too. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Accounts&SSO: define account and use it for Google Contacts/SyncML
On 10/08/2010 12:03 PM, Patrick Ohly wrote:
On Fri, 2010-10-08 at 08:28 +0100, Alberto Mardegan wrote:
On 10/07/2010 02:09 PM, Patrick Ohly wrote:
* Define "Google" account. Done by writing a
accounts-provider-plugin. Where is that API defined? How is such
a plugin installed? Is there an example?
The API is defined in libaccounts-ui, which is still stuck in the Nokia internal
legal processes to be open-sourced, we are all waiting. :-/
So we have Accounts&SSO in MeeGo 1.1, but we cannot use it? That can't
have been the intention. Please confirm and I'll escalate this :-/
No, it's not exactly like that. The accounts API are perfectly usable
without libaccounts-ui; this library (which for the time being is
missing from MeeGo) is helpful to write account provider and service
plugins and to load them.
But I think that here a step back is needed because your following
questions and later messages hint that we have a different idea of this
"accounts UI".
The accounts UI I'm talking about is one application which allows you to
create/edit accounts. It is plugin based, because the process of
creating/editing accounts can be quite different for different providers
-- if all plugins are developed by a single entity, then their UI will
be quite similar to each other, but if we allow any third-party
developer to write a plugin for his own service, then we want to give
him as much freedom as possible to design the UI as he feels like.
To manage this plugin mechanism, in Harmattan (Maemo6) we created
libaccounts-ui, which defines an API for writing account plugins. But
this library is not necessary to create accounts in MeeGo. It is a
library which uses libMeeGoTouch for the UI parts, libaccounts-qt for
creating the account and libsignon-qt for securely storing the account
credentials.
This centralized accounts UI replaces the accounts UI otherwise present
in other apps. You won't create your e-mail accounts from the e-mail
application and the chat account from the messaging application anymore;
instead, there'll be ways in this apps to invoke the centralized
accounts UI and create all your different types of accounts in there.
But of course, this is just the design we have in Maemo6 -- it's the
design that inspired the development of libaccounts-{glib,qt}, which
allows storing an account's settings in a single place, no matter what
kind of account it is. I would strongly advise application developers to
follow this centralized accounts UI concept, and that's why we are
getting libaccounts-ui opensourced -- but it's not the only possible way.
Still, if you want to escalate the issue of having libaccounts-ui
available, you have all my support, because I think it's worth it and it
should be in Nokia interest that MeeGo doesn't take a totally different
approach for the accounts UI.
How is the API specific to the UI? I understand that advanced use cases
(drawing your own widgets, for example) may have to depend on some UI
specific extensions, but isn't the common functionality UI independent?
libaccounts-ui is based on libMeeGoTouch. But indeed we could relax the
public API and make it work with any QGraphicsWidget.
The plugin UI needs to be embedded in the invoker application, or at
least chained to it by the window manager -- so it cannot be completely
UI agnostic.
In some cases the plugin could be just an XML file that describes various
parameters of the account creation process;
This is the part which I would expect to work regardless whether a MTF,
Qt, or implementation of the UI is used.
Well, the code which builds the UI out of the XML is part of
libaccounts-ui. So, yes, the XMl file is UI agnostic, but libaccounts-ui
cannot be.
and actually it will be the very
same file as the libaccounts-{qt,glib} provider files.
Do we have examples of those or documentation for them?
I guess you mean examples of the extended format. The basic one, used by
libaccounts-{qt,glib} can be as simple as this:
http://gitorious.org/accounts-sso/accounts-glib/blobs/master/tests/MyProvider.provider
A full example could be this:
Google(test)
Example google provider
icon-l-google
www.google.com
token1, token2
youtube.com
google.com
This is an example of a provider plugin for Google.com. It could have a
way to open the browser to the sing-up-link for creating new remote
accounts, and a way to store the credentials and secure the IdentityInfo
by letting applications holding the "nobody" token to use the "password"
authentication method, while allowing applications holding tokens
"token1" an
Re: [MeeGo-dev] Accounts&SSO: define account and use it for Google Contacts/SyncML
On 10/08/2010 09:43 PM, Patrick Ohly wrote: The initial IdentityInfo defines access rights. Applications are identified by strings (IdentityInfo::setAccessControlList()). Who defines these strings? The security framework isn't working in MeeGo yet, so how is this access control enforced at the moment in MeeGo? Is it possible to grant access to arbitrary apps? Without a working enforcement mechanism, the need to declare apps is just a maintenance problem without any gain. Without a working security framework, all apps can access any identity. My next question is about IdentityInfo::setMethod(const MethodName &method, const MechanismsList&mechanismsList). Methods and mechanisms are identified by strings. "Method" is something like the "password" method, but what are the mechanisms? Think of them as sub-methods. This makes most sense for the SASL plugin: for the "sasl" method, mechanisms map to the SASL mechanisms. We've talked about account handling. But from looking at the signon API, nothing seems to depend on an Account instance. So can we ignore that part and use just SSO without Accounts? Yes. The two frameworks makes most sense when used them together, but they are orthogonal: if you don't care about security and authentication methods you can store the password in plain text into the accounts DB; on the other hand if your application already has its own account storage and you don't want to share the account with other apps, then you could use SSO only. FWIW, the Account class has setCredentialsId()/credentialsId() methods. Are the identities created automatically for each account? No. And these methods are just helper methods: if you look at the implementation, you'll see that they simply access the value set in the "CredentialsId" key. This becomes off-topic for MeeGo-dev, but do you have a schedule for this? We probably can live without the account UI, but for the use case described above we need a password dialog. Or perhaps not. If every app is able to pop up its own dialog and allowed to store that password, then no signon-ui dialog should ever be needed - right? Well, the option to suggest is also possible, but not all apps can write to the identity. Actually, IIRC, with a working security framework only the application which created the identity is allowed to modify it (plus signon and signon-ui). Also note that some authentication plugins who directly authenticate over the network with the service provider (this could be the case of the advanced password plugin you suggested before) can detect that the password is wrong, because they receive an error code from the server. In such cases, before returning the response to the app, signond would get signon-ui to show a password query to the user and attempt the authentication once more (if the SessionData::UIPolicy allows that). And if successful, the new password would be stored in the SSO DB. So in some cases the application might not even know about this. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] SSO
On 10/07/2010 06:10 AM, Jia-Chi Lai wrote: Hi~~ I found that there is a session of SSO on 24 Sep 2010 11:52:11 (UTC). Is there any information of the session? document or slide ?? That is just a proposed session for the MeeGo unconference event in November. At the time being it's not even sure that it will take place at all. But if I'll prepare some slides, I'll share them in the mailing-list too. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Accounts&SSO: no identities signal
Hi Patrick, On 10/15/2010 01:23 PM, Patrick Ohly wrote: /usr/include/signon-qt/SignOn/authservice.h: /*! * Lists identities available on the server matching query parameters. * This signal is emitted in response to queryIdentities(). * * @param identityList list of identities information */ void identities(const QList &identityList); $ strings /usr/lib/libsignon-qt.so | grep identities ... identities(QList) The connect() also looks right: connect(m_service, SIGNAL(identities(const QList& )), this, SLOT(identities(const QList& ))); Note the namespace, it has been added recently. Looks like you are using the headers from a more recent version than the binaries. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] single sign on framework
On 10/27/2010 06:09 PM, Reijo Korhonen wrote: Hi, Does anyone know, how to set signond daemon on? I tried to simple start it with a command sudo /usr/bin/signond but process does not keep alive and /var/log/messages shows some errors Usually you wouldn't need to start it, it should be activated by D-Bus. The reason why it doesn't start is probably logged in either /tmp/signon_trace_file or ~/.signon/signon_trace_file (I should check where the log file is kept in MeeGo). [...] I am also grateful to have all information, what application use now Single Sign On Framework and what application are planned to use in MeeGo. I guess that currently it's pretty much unused, but ideally all applications needing some kind of service authentication should use it. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] accounts-sso source code for meego platform
Hi Aparna, On 11/08/2010 10:16 AM, Aparna Nandyal wrote: Hello, A couple of questions on the accounts-sso component: 1. Is source code from http://gitorious.org/accounts-sso expected to compile on MeeGo platform (I was using meego-netbook-ia32-1.1.80.3.20101022.1.img) ? accounts-glib, signon-glib compiled without any problem but accounts-qt, signon-qt, libaccounts-ui did not compile in their current state. Had to make some changes to get them compiling. accounts-qt and libaccounts-ui should compile too, at least in MeeGo:Trunk. It may be that on the 1.1 image you tried some dependencies are not yet there. signon-qt is a different case: the current git HEAD cannot be compiled in MeeGo. We are working to make it build, it should hopefully be done in a couple of days (one week max). After that is done, I will also push a new release of signon-qt to Meego Trunk:Testing. 2. Which is the right place to raise bugs related to accounts? Is Accounts& SSO component in bugs.meego.com the right place to raise bugs related to accounts or is there any other bugzilla for this component? That's the right component. But please notice that you should file bugs only about versions which are currently available in MeeGo, and not about what we have in the git HEAD. For discussions about development, feel free to use this mailing list. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
