Librem 5 — List of Apps in Development

Done! :smile:

1 Like

Also tested on the L5 :smiley:

3 Likes

I’ve started to work on making GNOME Recipes adaptive, so it can be added to the list.
Firstly I’m porting it to Rust because some people in the community are interested in the app to be written in the language. It’ll be my first GTK and also first Rust app, so hopefully I’ll complete it by the end of the year for testing.

7 Likes

Seems like we’ll have Chromium in addition to Epiphany and Firefox:

Edit: and how about NetSurf? :upside_down_face:

3 Likes

Yes! One more step to mobile Linux as a daily driver! I’m not a fan of Chrome/Chromium, but there are a couple of sites I use for work that require it.

What I thought what could be ported or developed for the L5 is:

  1. Corona Tracing App
    In Germany there is “Corona Warn App” which is already pretty privacy respecting by open source development and anonymous cryptographic protocols but it relies on Google’s respective Apple’s exposure notification API. The medical expertise comes from the Robert Koch Institute (RKI) which is a organization for experts of infective deceases. There has already an issue been filed to port it to Linux in relation to Linux smartphones and Laptops. To be honest I doubt that there will be development for such a niche as Linux smartphones from the developers of the official apps. I heard there are open source implementations of tracing protocols may be helpful is case of community initiatives for porting the app. Also there are efforts for international interoperability of tracing apps (at least across Europe) but I don’t know the state of development. Maybe I should mention that the official apps don’t work with older android phones. I am not sure but that maybe because the those devices don’t get upgrades with the exposure notification API. Maybe there are community efforts to help out. Maybe this should become a distinct topic so that people can debate and engage.
  1. TV Browser
    TV Browser is by far the best app I know for tasks around the TV program. That would be worth porting. There is an android app and a desktop app based on Java. I don’t know it’s architecture. Maybe there are underlying libraries for reuse and use them with a knew Linux / L5 fitting UX. It has plugins for marking, remembering TV shows and creating calendar reminders, etc. A TV guide app could be a companion of a TV watching app. Maybe simply by launching a media player with the streaming URLs.
    There is already a TV Guide app under development for the L5. Does somebody know if this is a port or fork of an existing desktop app.

  2. ZAPP TV streaming app
    This app does stream German TV channels and gives access to the mediathek for watching and downloading archives materials. It is very easy. It gives access to Deutsche Welle and Bundestags TV, too.

  3. A standalone dedicated bookmarks app
    It is common to store bookmarks in browsers but I think it would be better to have a dedicated bookmark manager because URIs are not only found in the web and in browsers. Media players can take URIs to streams. SSH client needs to know which host to connect to. Basically many kinds of networking takes URIs. Also people use multiple browsers. Nobody wants to manage multiple bookmark databases.

I thought maybe I could try to develop #4 as a first app for mobile Linux. I CAN’T PROMES ANYTHING! Maybe I will use MetaLink as the bookmark format.
However I thought about which language respective platform I should take. Scala native? Haskell? OCaml? With the latter two I have no practical experience. It’s the same for me with Scala native cross compilation. What I already did was to build a native image from JVM Bytecode with Graal VM’s native-image tool. So the chain goes Scala + Java source -> compiler -> bytecode -> graal vm native-image -> native executable. Also there was the question which GUI toolkit to take. I have no experience with Java FX / Open JFX. To my surprise the most used language of OpenJFX is C++. I don’t remember if there was an ARM build.

So i decided to take the easy path for a first experiment and created a simple GUI with good old Swing and ordinary Scala to see if Swing works on my PinePhone PMOS edition. The result is that it starts and shows up the frame alias window but it is completely white. It did not always fill the screen completely. At the bottom there was a space not filled by the window, probably where the virtual keyboard is, but the behavior was not deterministic. Seems after recent updates it fills the screen correctly. The frame was blank but it should show some buttons, which works fine on desktop. Maybe I should not rely on the system’s look-and-feel. Haven’t tried default (“Metals”) look-and-feel, yet.

So I did not come far, yet. In general it would be good if Java / Swing works. For example for legacy apps. I personally liked Swing. Also it is as light-wight as Java and doesn’t have much external dependencies. It has to be shown if flexible UX can be made with Swing for L5 and desktop screens. The easiness of Java and Swing comes from the write-once-run-everywhere principle which comes in very handy again instead of write-once-compile-everywhere or cross compilation (which is probably not hard, but dependencies have to be considered). Actually startup times where not very long but it was just a frame and not a full blown application. With a native app on the other side the startup times are really low.

  1. A better password manager
    What I don’t like on common password managers is that the kdbx database have all in one file. Of course you can have multiple dbs. What I think of is to store each entry like credentials for example.com in a separate file. Maybe even each transaction in a different file like with the event sourcing concept. That way the db becomes much more flexible e.g. for sync across multiple devices or sharing only a subset of entries. I don’t think that this affects encryption security but I might be wrong. Cryptography can be a very tricky subject. Any comment on that is appreciated.
    Also it would be a possible killer feature if the L5 gets a password manager which can autotype credentials like a USB or Bluetooth keyboard into other devices like a desktop PC. That way the sync problem fades away. You store all credentials on the L5 and if you need them on another device like a desktop you connect it to the L5 via USB or Bluetooth (if you trust it ;)) and tell the L5 password manager app to autotype it. This function does not necessarily need a new password manger. An existing one could be enhanced with this.
3 Likes

You would need to be careful with naming. On the one hand, for the naming to be at all usable, you would need something like what you show as an example. On the other hand, that is leaking a lot of information i.e. it is leaking the identity of and existence of sites that you have credentials for, which is itself useful information to an attacker.

I guess you could put all those files in an encrypted folder.

On balance, no, I wouldn’t do this - but happy to be persuaded otherwise.

Thank you for the hint. You are right, naming a file by the credential’s domain like e.g. facebook.com would be leaking that the user has an fb account. I saw that, too, and I thought I could perhaps use a hash of the domain name as a file name. Other options would be to use incremental numbers or random numbers. At startup the program has to read all files to be able to show a list of entries. Hashes have the advantage that they can be recomputed from plain domain names after program startup within the program if those files have to be accessed again. That way they can be accessed “randomly” or better selectively.

As credentials are among the most valuable data a user has highest security criteria has to be layed out. First of all an appropriate programming language and platform has to be chosen. One might think of c/c++ first because of their total control of memory. I think we have other options like Haskell or Ocaml because, as far as I know, they do support memory pinning and may help avoiding other bugs and vulnerabilities by code complexity. As I do not have practical experience with those two languages I would have to proof it. Especially when the user inputs the master password it has to be used to decrypt the data and have to be securely overridden after that. I would like to proof that with reverse engineering tools.

Also I consider to never have the master password in memory in the first place. Instead I could put the master password into a hash or password derivation function and passing the hash to the actual password manager program. Then instead of the plain master password it’s hash would be used for encryption / decryption. Still the master password’s hash has to be erased from memory.

Further a second master password could be used to increase security by using it to encrypt the actual password in an entry file. So there is master password 1 for encryption of the files and master password 2 for the encryption of the password inside the encrypted files. So there would be double encryption.

The key questions are:

  1. Will using a hash or derivative password (derived from the plain text master password) instead of the plain text master password increase or decrease security?
  2. Will the described double encryption increase or decrease security?

Yes and no. While there are niche considerations around liquid nitrogen attacks that may mean that the choice of programming language is important, that wouldn’t be my first consideration. Other considerations are: availability on the platform, performance on the platform, familiarity to the programmer, familiarity to the community.

Come up with a solid design. That is more important than the choice of language. With a solid design, anyone can reimplement in the preferred programming language - and there’s no reason why clients in different languages can’t access the same password store.

I don’t think it makes a great deal of difference from the perspective of an attack against memory. If the attacker can copy arbitrary pieces of memory then stealing the KDF-derived hash is just as good as stealing the plain text master password - even though the latter may never be known to the attacker. (Nevertheless, you should use a KDF.)

Also, if an attacker can really copy arbitrary pieces of memory then there is a severe risk that the actual credentials that you are trying to protect will get stolen.

Also, in some scenarios where an attacker can copy arbitrary pieces of memory, you have a much bigger problem than whether your password store can be compromised.

Also

This.

Designing something that is truly robust is hard. Even algorithms devised by luminaries in the field have subsequently been shown to have chinks in their armor. So, I would be inclined not to be implementing a password manager for the community.

I don’t think your original motivation is compelling.

I would partition credentials according to sensitivity e.g. credentials for random web sites (low sensitivity) and e.g. credentials for internet banking (high sensitivity) - and use multiple files for that.

But having all the credentials in one file would not necessarily prevent accessing subsets or even syncing subsets / selective syncing.

Syncing is an inherently risky concept in respect of password managers. You would need to ensure that your design for that is solid.

It is definitely a risk to encrypt each credential into a separate file but encrypted using the same master password unless that is designed carefully. However there is no way for someone to assess that for risk without a detailed design and the expertise to do so.

As a fun visual example (not intended to be an exact analogy) look at the encrypted penguin: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#ECB

Thanks for your reply.

I edited my post to add “platform” while you where writing. ^^

Yes I thought it would be good if the master password could maybe protected in case of emergency.

Me personally would never copy any credentials to untrusted machines. Not to PCs of other people and I would not input them into those. And not to servers out of my control like dropbox or something like that. I thought maybe syncing with fsync between my devices would be possible.

I see, I see. I was afraid of something like this. The separate files will have some plaintext like XML structures in common.

I would not implement any cryptographic algorithms myself. At least not for this project. :wink: I consider using AES. But the algorithm will be configurable, so that it can be changed later on. I would have to dig into the characteristics of AES get an idea of it’s quality for the multi file design.

And yes, concept, design and architecture are fundamental. But those do not float in the air. At some point they manifest in concrete implementations. When a user’s system is compromised by malware the user has severe problems but if the attacker gets those credentials the problems get much bigger. This is the situation a password manager should be prepared for. Otherwise we could consider the user’s system as trusted and would not have to encrypt data anyway.

As from the perspective of the program I do not have control over the outside world like the OS and any protection mechanisms. A malware could have access to the programs memory. This is the scenario for which responsible handling of the master password and credentials could be put place. If we consider that is is not relevant or does not happen there would be no need for bothering with in memory security. Also at some point there is always plaintext in memory. So it just gets cumbersome for an attacker but not impossible. So maybe this is just security by obscurity. Maybe the best that can be done in this situation.

And when it comes to implementation of such a concept choosing the wrong platform can be a pitfall. E.g. a generational garbage collector could silently copy plain passwords in memory so that it can’t be securely erased.

I think for such important data the bar has to be raised.

The point of that example is that even with a secure encryption algorithm (like AES, as far as I know), if it is used in the wrong mode or otherwise inappropriately - for the specific application - then the result can be inappropriate. (Unfortunately that Wikipedia image doesn’t say which encryption algorithm specifically was used for that example.)

For sure. If you use a managed code environment then there are massive advantages in terms of program reliability (and hence ruling out certain attacks), but you do give up a certain level of control - which may prevent you from guaranteeing that all copies of sensitive data are erased in memory once no longer needed.

Against that, it must be said that if you use libraries (or operating system functionality) in any environment, it can be that those libraries or other code similarly thwart you. Even in an open source situation, it may be impractical to control this.

You can only do what you can do.

Have you looked at libsecret? I haven’t, but it might be what you need. Also, they are looking for an intern. https://blogs.gnome.org/dueno/libsecret-is-accepting-outreachy-interns-as-well/

It seems like I can not add a PureOS app on openrepos.net.
I also tried to add “/pureos-app” to the URL, but this gives me a “Access denied”-page.
Is this just a temporary bug and is this maybe connected to the cert issue?

Will there be a TuneIn version for the L5?

No need to ask about an RSS feed reader, I guess. (It would be weird if no one was developing one of those.)

Newsflash and feeds are two RSS readers that work

1 Like

Cool! I’ll check 'm out as soon as the L5 arrives… :wink:

Not sure if that fits your need:
https://www.passwordstore.org/

It stores each password in a seperate file

There is an extension “pass-tomb” which encrypts all this files in a big file.

The decryption fir both can be limited to a key which is stored in a smartcard.

And there is a GUI for it I wrote:

2 Likes

Hi,

I would like to contribute this app called PicPlanner. It is meant for photographers in order to plan the position and time for an photograph (sunset, sunrise, moonrise, blue hour, golden hour, maximum elevation of the milky way etc.). There is still a lot of work to do but I think in a few weeks it should be usable. The UI is adaptive due to libhandy.

Calculating the position of the sun, moon and milky way:

6 Likes

I have the almost exact same story. I came up with a terrible logo, the company riffed on it and made it even worse. They used it for years. To be honest it’s a relief they have now closed down.