Revision history [back]

So, I got my Jolla yesterday and within 5 minutes I had to discover that my email/XMPP passwords are stored in plain form inside a user-readable file with no security measures to speak of. It goes without saying that for many nerds (the core clientele of Jolla at this point), something like this is a PR disaster.

I'd like to get a discussion going about how to approach this problem. Right mer and nemo have inherited a rather dated libsignon/libaccounts from the days of meego along with the security issues mentioned. According people on the #mer IRC channel "it's a huge pain" anyway, so why not go ahead and drop it in favor of something else.

One easy solution to the problem could be a simple (fuse) filesystem that offers a different view to each service accessing it. (Along the lines of how Plan9 exposes different resources to each process for those who are familiar with that approach.) Programs and Apps already know how to read and write files, so there would be no added complexity on the application side. The OS just transparently provides a unique directory for each process to write its sensitive data to while its contents remain invisible to any other process. The contents of those directories can be stored in a suitably encrypted container in the back-end, unreadable by anyone except the file system process.

(Something like this might even be a decent starting-point for proper application sandboxing which currently is also not in place.)

Another solution might be a simple socket API with suitable crypto-container in the back-end (unlocked at boot-time). Something like a kwallet keyring or similar. Personally, I am not too fond of such dedicated APIs, but this approach shouldn't go unmentioned either.

So, what are your thoughts?

So, I got my Jolla yesterday and within 5 minutes I had to discover that my email/XMPP passwords are stored in plain form inside a user-readable file with no security measures to speak of. It goes without saying that for many nerds (the core clientele of Jolla at this point), something like this is a PR disaster.

I'd like to get a discussion going about how to approach this problem. Right mer Mer and nemo have inherited a rather dated libsignon/libaccounts from the days of meego along with the security issues mentioned. According people on the #mer IRC channel "it's a huge pain" anyway, so why not go ahead and drop it in favor of something else.

One easy solution to the problem could be a simple (fuse) filesystem that offers a different view to each service accessing it. (Along the lines of how Plan9 exposes different resources to each process for those who are familiar with that approach.) Programs and Apps already know how to read and write files, so there would be no added complexity on the application side. The OS just transparently provides a unique directory for each process to write its sensitive data to while its contents remain invisible to any other process. The contents of those directories can be stored in a suitably encrypted container in the back-end, unreadable by anyone except the file system process.

(Something like this might even be a decent starting-point for proper application sandboxing which currently is also not in place.)

Another solution might be a simple socket API with suitable crypto-container in the back-end (unlocked at boot-time). Something like a kwallet keyring or similar. Personally, I am not too fond of such dedicated APIs, but this approach shouldn't go unmentioned either.

So, what are your thoughts?

So, I got my Jolla yesterday and within 5 minutes I had to discover that my email/XMPP passwords are stored in plain form inside a user-readable file with no security measures to speak of. It goes without saying that for many nerds (the core clientele of Jolla at this point), something like this is a PR disaster.big concern.

I'd like to get a discussion going about how to approach this problem. Mer and nemo have inherited a rather dated libsignon/libaccounts from the days of meego along with the security issues mentioned. According people on the #mer IRC channel "it's a huge pain" anyway, so why not go ahead and drop it in favor of something else.

One easy solution to the problem could be a simple (fuse) filesystem that offers a different view to each service accessing it. (Along the lines of how Plan9 exposes different resources to each process for those who are familiar with that approach.) Programs and Apps already know how to read and write files, so there would be no added complexity on the application side. The OS just transparently provides a unique directory for each process to write its sensitive data to while its contents remain invisible to any other process. The contents of those directories can be stored in a suitably encrypted container in the back-end, unreadable by anyone except the file system process.

(Something like this might even be a decent starting-point for proper application sandboxing which currently is also not in place.)

Another solution might be a simple socket API with suitable crypto-container in the back-end (unlocked at boot-time). Something like a kwallet keyring or similar. Personally, I am not too fond of such dedicated APIs, but this approach shouldn't go unmentioned either.

So, what are your thoughts?

So, I got my Jolla yesterday and within 5 minutes I had to discover that my email/XMPP passwords are stored in plain form inside a user-readable file with no security measures to speak of. It goes without saying that for many nerds (the core clientele of Jolla at this point), this is a big concern.

I'd like to get a discussion going about how to approach this problem. Mer and nemo have inherited a rather dated libsignon/libaccounts from the days of meego along with the security issues mentioned. According to people on the #mer IRC channel "it's a huge pain" anyway, so why not go ahead and drop it in favor of something else.

One easy solution to the problem could be a simple (fuse) filesystem that offers a different view to each service accessing it. (Along the lines of how Plan9 exposes different resources to each process for those who are familiar with that approach.) Programs and Apps already know how to read and write files, so there would be no added complexity on the application side. The OS just transparently provides a unique directory for each process to write its sensitive data to while its contents remain invisible to any other process. The contents of those directories can be stored in a suitably encrypted container in the back-end, unreadable by anyone except the file system process.

(Something like this might even be a decent starting-point for proper application sandboxing which currently is also not in place.)

Another solution might be a simple socket API with suitable crypto-container in the back-end (unlocked at boot-time). Something like a kwallet keyring or similar. Personally, I am not too fond of such dedicated APIs, but this approach shouldn't go unmentioned either.

So, what are your thoughts?

So, I got my Jolla yesterday and within 5 minutes I had to discover that my email/XMPP passwords are stored in plain form inside a user-readable file with no security measures to speak of. It goes without saying that for many nerds (the core clientele of Jolla at this point), this is a big concern.

I'd like to get a discussion going about how to approach this problem. Mer and nemo have inherited a rather dated libsignon/libaccounts from the days of meego along with the security issues mentioned. According to people on the #mer IRC channel "it's a huge pain" anyway, so why not go ahead and drop it in favor of something else.

One easy solution to the problem could be a simple (fuse) filesystem that offers a different view to each service accessing it. (Along the lines of how Plan9 exposes different resources to each process for those who are familiar with that approach.) Programs and Apps already know how to read and write files, so there would be no added complexity on the application side. The OS just transparently provides a unique directory for each process to write its sensitive data to while its contents remain invisible to any other process. The contents of those directories can be stored in a suitably encrypted container in the back-end, unreadable by anyone except the file system process.

(Something like this might even be a decent starting-point for proper application sandboxing which currently is also not in place.)

Another solution might be a simple socket API with suitable crypto-container in the back-end (unlocked at boot-time). Something like a kwallet keyring or similar. Personally, I am not too fond of such dedicated APIs, but this approach shouldn't go unmentioned either.

So, what are your thoughts?

So, I got my Jolla yesterday and within 5 minutes I had to discover that my email/XMPP passwords are stored in plain form inside a user-readable file with no security measures to speak of. It goes without saying that for many nerds (the core clientele of Jolla at this point), this is a big concern.

I'd like to get a discussion going about how to approach this problem. Mer and nemo have inherited a rather dated libsignon/libaccounts from the days of meego along with the security issues mentioned. According to people on the #mer IRC channel "it's a huge pain" anyway, so why not go ahead and drop it in favor of something else.

One easy solution to the problem could be a simple (fuse) filesystem that offers a different view to each service accessing it. (Along the lines of how Plan9 exposes different resources to each process for those who are familiar with that approach.) Programs and Apps already know how to read and write files, so there would be no added complexity on the application side. The OS just transparently provides a unique directory for each process to write its sensitive data to while its contents remain invisible to any other process. The contents of those directories can be stored in a suitably encrypted container in the back-end, unreadable by anyone except the file system process.

(Something like this might even be a decent starting-point for proper application sandboxing which currently is also not in place.)

Another solution might be a simple socket API with suitable crypto-container in the back-end (unlocked at boot-time). Something like a kwallet keyring or similar. Personally, I am not too fond of such dedicated APIs, but this approach shouldn't go unmentioned either.

So, what are your thoughts?