11 ms·

New F-Droid repository format for faster and smaller updates

523 points by mikece 4y ago

eighthave 4y ago
This is a full revamp of a bunch of the key guts of the app. We hope that other F-Droid-compatible clients like Classic, Foxy, NeoStore, droid-ify, etc. can benefit from this revamp as well: we've split out this core functionality into libraries. This should fix lots of stability issues. I think it is also important to point out that the official F-Droid client is stable for the core contributors, and that's mostly because a) we are the devs and we fix the bugs we encounter, and b) we report the bugs we can't fix. I think most F-Droid contributors are using Google-free devices these days, so that's where it works best, especially when built into the ROM like CalyxOS, Lineage-for-microG, etc. Unfortunately, that means we pay less attention to how things run on Google devices. So if you're running F-Droid on a Google device, please be sure to report issues so we are aware of them!
Waterluvian 4y ago
I’m trying to understand the JSON merge patch RFC the post refers to. How does that describe “this key nolonger exists”? Does it perceive ‘key: null’ as being the same as a key not existing? Edit: oh, it’s in the RFC. I just missed it: “ This design means that merge patch documents are suitable for describing modifications to JSON documents that primarily use objects for their structure and do not make use of explicit null values. The merge patch format is not appropriate for all JSON syntaxes.” So it remains simple without any sort of DSL needed to describe changes like “remove this key” by somewhat hijacking ‘null’. Seems like a footgun if you happen to use ‘null’ as a possible value for your schema.
- entropicdrifter 4y ago
  >Seems like a footgun if you happen to use ‘null’ as a possible value for your schema. To be fair, using "null" as a value in your schema without handling the cases where a given key is missing (and therefore the value is null) is also a footgun.
  - Etheryte 4y ago
    I think the main point here is that key present with a null value and key not present are two distinct states and squashing them down into one loses that information.
    - entropicdrifter 4y ago
      Right, but my main point here is that if your business logic cares about the distinction, you've created a pointless footgun 99% of the time. If you care because you're worried about formatting issues or string corruption, there are a million better ways to check for those.
  - mattashii 4y ago
    > and therefore the value is null That depends on the interpreter: A good implementation of json distinguishes between defined and undefined keys in the object. Think hasattr(obj, "key") in python, or undefined != obj["key"] in js.
    - Waterluvian 4y ago
      Gosh. If “undefined” was part of JSON and it was always 100% semantically identical to “this key doesn’t exist on this object” then I could see myself not hating “undefined”. Unfortunately “undefined” in javascript isn’t even the same as “key doesn’t exist.” It’s just another null type.
      - jffry 4y ago
        Until you try JSON.stringify({a: null, b: undefined})
      - mananaysiempre 4y ago
        Which in turn led V8 to invent TheHole[1], a true unset value, as an implementation detail (unavailable to the user). Honestly, it seems to me that pre-strict-mode JavaScript actually made a fair attempt at making "undefined" a genuine missing value, except that then implied semantics people disliked, like an undefined variable reference having the value of "undefined" instead of being an error. Lua seems mostly OK having an actual nil, though. (There is admittedly some gnarliness, like a vararg function f being able to distinguish f(1,2,nil) from f(1,2).) [1] https://stackoverflow.com/q/61420580 https://stackoverflow.com/q/61420580
geokon 4y ago
I didn't realize the app was still being worked on. It's been years since the UI update and it's always been amazingly buggy (across 3 different phone). I'm always impressed by how broken it is - especially if you have a slow connection. Downloads will randomly go into a weird frozen state where they can't be stopped. The download status will change when you change tabs/sections. Sometimes download will go past 100% (I managed to get past 200% the other day). If you leave FDroid in the background or lock your phone then it's almost guaranteed to not work I almost exclusively use FDroid, it's an amazing project. But I've never seen an app with so many issues
- hunter2_ 4y ago
  Agreed. I wonder if it falls into traps that simply didn't exist in the past, and release notes about breaking changes regarding those increasing blurry-but-not-killed modes were ignored.
- abdullahkhalids 4y ago
  Every few months, the app starts to crash constantly. Meaning, I open it, it crashes, then for some reason starts up again on its own, crashes again, and the cycle continues. I usually have to restart my phone, uninstall the app, and reinstall again from scratch.
- soiler 4y ago
  Weird, I've never had an issue except with trying to open updates from the notifications dropdown.
  - geokon 4y ago
    I think if you live close to their servers maybe most of the issues would not be noticeable. If the app downloads and installs while you have the app page open then it seems to go smoothly. From Asia, I always get DSL speeds and need to leave the app/phone open for an extended amount of time to download even the smallest app
    - 4y ago
eointierney 4y ago
Thank you! F-Droid is one of those projects that adds so much peace of mind and usability to my computational life. It is a must-have.
- stefan_ 4y ago
  Just used it again today when some service asked me to use one of these generic 2FA OTP token apps. It first recommended the Microsoft one but that one literally wouldn't work unless you accept transmitting usage data, for a kind of app that is both calculator-levels of complexity and uniquely ill suited to transmitting any data. Found something simple and perfectly good working on FDroid.
JaggedJax 4y ago
My F-Droid would not auto-update, attempting to manually get the update through the app refused to load at all, and downloading from their homepage gave me an old version. I had to download the specific version directly from their package page via a browser: https://f-droid.org/packages/org.fdroid.fdroid/ https://f-droid.org/packages/org.fdroid.fdroid/ This seems to have resolved the self-auto update issue I had as well. I can now see the F-droid client page from within the F-droid client itself. It's great to see F-droid client updates. The app can be clunky at times, but they are doing great work with maintaining the repo. I feel like a better client experience would draw in and keep more users, so every step in that direction is appreciated.
- efreak 4y ago
  > downloading from their homepage gave me an old version. This is because the FDroid website does not expose the latest version of apps. The website itself is a static Jekyll website, and I've never found any information to indicate that the app listings aren't part of that, apart from them being missing from the source repos (which they would be if it's generated from the index at runtime).
- BlueGh0st 4y ago
  For anyone else following these steps: Be sure to scroll down to click "Download APK" below the version that you want to download, and not the giant "DOWNLOAD F-DROID" button right above it. This was a bit confusing on mobile before I came back and scrolled down the page some.
Egoist 4y ago
My Client didn't receive the update even after refreshing the repository. I was able to get the new version by searching for F-Droid and going to the "versions" section and click update on the latest version
- deleted 4y ago
  [deleted]
pserwylo 4y ago
Congratulations team. I was involved in the project for quite some time years ago. Indeed I ported the original “Read the full index.xml into Java memory using a giant DB class” with the first “Stream entries from XML into the database, and make use of ContentProviders” because they seemed like the “Android way to do things” at the time. I also worked on the migration from XML to JSON metadata. At the time this was done, we needed to updated the metadata format to support internationalisation of metadata and the inclusion of images. To see Torsten and others working on replacing my crufty-passed-their-use-by-date ContentProvider code with a modern Kotlin + Room implementation is heart warming. If any of you are reading this, please accept my deepest sympathies for having to pull that code out and rework it - that is not something I would have enjoyed doing! It is even better that it all lives in libraries that other clients can adopt if they choose so they don’t need to reinvent the wheel. For those interested, yes, I am also responsible for writing the bulk of the code for the “new” (now several years old) UI in the offical client which often gets maligned on HN (and this thread is no exception). At the time I did my best to fight off edge cases and quirks of the Android system. F-Droid needs to ask Android which apps are installed and what their signatures are, then cross verify that with its own database to tell you whether updates are available. It also needs to know whether new apps have been installed outside of F-Droid since last time you opened it, etc. It also needs to pass downloaded .apk files to the system and request for them to be installed, then wait for confirmation from the system. The API’s Android provide for this kind of work, but they always seemed flakey, unwieldily, and slow to respond. The whole experience is full of race conditions, and each bistro seems to handle it ever so slightly differently. I am still proud of how much we managed to achieve, and I’m also very pleased with the fact we were able to do so much great work around internationalised metadata, screenshots, encouraging donations to app developers, etc. But I’d be lying if I said I wasn’t still a little disappointed that I couldn’t iron out all of the kinks. Life circumstances meant that I drifted away from the project and no longer contribute (other than via Liberapay donations to the wonderful fdroiddata team). However I would love to revisit the project in the future to see if I can address some of those edge cases to ease the user experience for all of us. You may have noticed that for such an amazing project, used by many people (not just the client, but the entire infrastructure), there has been comparatively few contributors. Despite that, I am still extremely fond of the value they bring to the Free and Open Source ecosystem.
andyonthewings 4y ago
I found that my fdroid has not been updated to the latest release mentioned in this post (1.16). I opened it and pulled down to refresh, but it didn't show any available updates to fdroid. I opened the fdroid info page in the app, and at the bottom I saw 1.16.1 was available but 1.15.6 (the installed version at time) was labeled “suggested”, not sure what that meant. I selected 1.16.1 and it installed and ran smoothly anyway.
- deleted 4y ago
  [deleted]
- pbhjpbhj 4y ago
  Same behaviour for me, but I chose not to install. I like to wait a while (couple of weeks at least) unless critical security bugs are indicated.
RicoElectrico 4y ago
It shouldn't need to download the whole repo index for a mobile app store. It's a flawed assumption to begin with.
- blendergeek 4y ago
  Offline search and metadata is a really nice feature to have. I'm glad it is present and I'm happy to see it being improved rather than abandoned.
- Aachen 4y ago
  I've got mixed feelings about that as well, but on the whole it's about even and I'm not sad that the search is local and instant. It's not that big a deal to me to download a few megabytes on top of the f-droid apk. Then again, to download anything (including screenshots and other app info, let alone the app itself) you need a server connection so it's only mildly useful to not have to ask a server. And the search algorithm is... nonexistent I think is the most correct word to use. You get what you ask for. The top three hits for "camera" are Telegram and two identical looking SIP clients, of course. (There's not being influenced by algorithms and there's this.) I wonder if te project would accept a better algo if I'd contribute one; I've made one before at work for a not dissimilar dataset so I have some notion of what works, though it's not rocket science anyway.
- notepalf 4y ago
  I believe the whole repo is also used to check available app updates
- jeroenhd 4y ago
  It's not strictly necessary, but if the entire repo can fit inside 8MiB of compressed data I can understand why they chose this rather than server-side search. That's "three clicks on Twitter" in terms of data, not exactly the end of the world, though less is always better. F-Droid's main servers are always overloaded anyway, so just sending a nice and cacheable compressed archive seems like a fine trade-off to me.
  - 4y ago
TrueSlacker0 4y ago
"Updating only what has changed" So... An rss feed?
- JustSomeNobody 4y ago
  More like a patch.
lenkite 4y ago
Why not just use a SQLite db ? Far more size efficient than JSON.
- IshKebab 4y ago
  Exactly my thoughts. JSON is totally the wrong format in the first place.
  - eighthave 4y ago
    JSON is the file format, it is then parsed and stored in the local SQLite
tommica 4y ago
F-droid is an amazing project, and I am so glad it exists, because there are so many useful apps that people have made there that make my phone experience enjoyable.
franky47 4y ago
> stronger digest algorithm for repository signing: We now use SHA256 instead of SHA1 for the index signature Neither SHA-1 nor SHA-256 are signing constructs, they are hash functions. They provide integrity, not authenticity. For this kind of thing (a central authority signing and public clients verifying), you'd need a public key signature scheme, like ECDSA or EdDSA.
- kapep 4y ago
  > Neither SHA-1 nor SHA-256 are signing constructs, they are hash functions Well that's why they said "stronger digest algorithm". As far as I understand, the repository index is hashed (now using SHA-256 instead of SHA-1) and this hash is then signed as usual, using whatever public key signature scheme they are using.
- bheadmaster 4y ago
  The usual process of signing a bunch of data is to hash it and then encrypt it with public key encryption, so the hash function is as important as the public key encryption scheme. If the hash is weak, an attacker may be able to construct compromised data that hashes to the same hash, and the whole signature becomes worthless.
- dspillett 4y ago
  It isn't common to encrypt or sign the full content using asymmetric encryption. For encryption you usually pick a large random key for symmetric encryption, encrypt the body with a strong symmetric cypher and that key, and encrypt the symmetric key with your asymmetric method and the intended recipient's public key. For signing, you use a suitable secure hash function to produce a digest of the content, when sign the digest using your private key. Choice of digest function is as important as your choice in encryption method as an exploitable issue that allows you to generate the same digest for different content means that the signature, while secure in itself, is worthless because what has been signed is no longer effectively deterministic. tl;dr: So when they say “digest algorithm for repository signing” they don't mean that they are using the SHA256 result as a signature, but that they use SHA256 to generate the digest that is then signed.
eska 4y ago
Because of perf/size issues they switched to JSON..? What were they using before?
- guntherhermann 4y ago
  XML?
- benibela 4y ago
  JSON Looks like they switched from downloading the entire JSON on updates to downloading a patch
hydroid7 4y ago
Thank you f-droid for having a consistent UI since years.
- pbhjpbhj 4y ago
  Consistency is good. But I find the update flow to be annoying. Touch 'updates' tab, doesn't show you the updates until you pull down (with no affordance), update are summarised but not listed in the big space for updates to be listed, "update all" then doesn't update all but instead lists the updates in that big space, tap "update" on each item listed, you get a popup asking if you want to update it (because the two previous choices of "update", after already going to the update tab, might have been a mistake?). I appreciate it, but it's a weird flow. I'd expect touch "update" tab would run the "check for updates" without needing the pull down (maybe set a cache-time in settings); "update all" would do all the updates without any other taps (or with at most one [per app]).
  - eighthave 4y ago
    Interesting points, I agree the Updates tab could do better there. Update All is implemented if you have F-Droid Privileged Extension installed, it could also be implemented when it is directly installed, if someone wants to contribute there.
  - llanowarelves 4y ago
    Not being able to update multiple at once is an android security thing isn't it?
    - pbhjpbhj 4y ago
      Maybe, Google Play can do "all updates", but they maybe do shenanigans.
1vuio0pswjnm7 4y ago
The apps I get from F-Droid are generally not ones that will be frequently updated. In the case that there are updated versions available, I prefer to look at the source code changes before making a decision to update. (That, to me, is the benefit of F-Droid: Android apps with source code available.) As such, I do not use the F-Droid client app. I prefer to download the apks from the F-Droid site myself.
bheadmaster 4y ago
I'm really glad this is fixed. I like to make a point of keeping my software up-to-date, but waiting for F-Droid to download/uncompress/analyze the repository index has annoyed me so much I've stopped doing it whatsoever, unless I make a conscious decision to actually do it and invest time time.
kseistrup 4y ago
I gave up using the F-Droid app a long time ago. I tried a few alternatives and settled for Droid-ify: https://f-droid.org/en/packages/com.looker.droidify/ https://f-droid.org/en/packages/com.looker.droidify/

523 points by mikece 4y ago

This is a full revamp of a bunch of the key guts of the app. We hope that other F-Droid-compatible clients like Classic, Foxy, NeoStore, droid-ify, etc. can benefit from this revamp as well: we've split out this core functionality into libraries. This should fix lots of stability issues. I think it is also important to point out that the official F-Droid client is stable for the core contributors, and that's mostly because a) we are the devs and we fix the bugs we encounter, and b) we report the bugs we can't fix. I think most F-Droid contributors are using Google-free devices these days, so that's where it works best, especially when built into the ROM like CalyxOS, Lineage-for-microG, etc. Unfortunately, that means we pay less attention to how things run on Google devices. So if you're running F-Droid on a Google device, please be sure to report issues so we are aware of them!

Waterluvian 4y ago

I’m trying to understand the JSON merge patch RFC the post refers to. How does that describe “this key nolonger exists”? Does it perceive ‘key: null’ as being the same as a key not existing? Edit: oh, it’s in the RFC. I just missed it: “ This design means that merge patch documents are suitable for describing modifications to JSON documents that primarily use objects for their structure and do not make use of explicit null values. The merge patch format is not appropriate for all JSON syntaxes.” So it remains simple without any sort of DSL needed to describe changes like “remove this key” by somewhat hijacking ‘null’. Seems like a footgun if you happen to use ‘null’ as a possible value for your schema.

entropicdrifter 4y ago
>Seems like a footgun if you happen to use ‘null’ as a possible value for your schema. To be fair, using "null" as a value in your schema without handling the cases where a given key is missing (and therefore the value is null) is also a footgun.
- Etheryte 4y ago
  I think the main point here is that key present with a null value and key not present are two distinct states and squashing them down into one loses that information.
  - entropicdrifter 4y ago
    Right, but my main point here is that if your business logic cares about the distinction, you've created a pointless footgun 99% of the time. If you care because you're worried about formatting issues or string corruption, there are a million better ways to check for those.
- mattashii 4y ago
  > and therefore the value is null That depends on the interpreter: A good implementation of json distinguishes between defined and undefined keys in the object. Think hasattr(obj, "key") in python, or undefined != obj["key"] in js.
  - Waterluvian 4y ago
    Gosh. If “undefined” was part of JSON and it was always 100% semantically identical to “this key doesn’t exist on this object” then I could see myself not hating “undefined”. Unfortunately “undefined” in javascript isn’t even the same as “key doesn’t exist.” It’s just another null type.
    - jffry 4y ago
      Until you try JSON.stringify({a: null, b: undefined})
    - mananaysiempre 4y ago
      Which in turn led V8 to invent TheHole[1], a true unset value, as an implementation detail (unavailable to the user). Honestly, it seems to me that pre-strict-mode JavaScript actually made a fair attempt at making "undefined" a genuine missing value, except that then implied semantics people disliked, like an undefined variable reference having the value of "undefined" instead of being an error. Lua seems mostly OK having an actual nil, though. (There is admittedly some gnarliness, like a vararg function f being able to distinguish f(1,2,nil) from f(1,2).) [1] https://stackoverflow.com/q/61420580 https://stackoverflow.com/q/61420580

geokon 4y ago

I didn't realize the app was still being worked on. It's been years since the UI update and it's always been amazingly buggy (across 3 different phone). I'm always impressed by how broken it is - especially if you have a slow connection. Downloads will randomly go into a weird frozen state where they can't be stopped. The download status will change when you change tabs/sections. Sometimes download will go past 100% (I managed to get past 200% the other day). If you leave FDroid in the background or lock your phone then it's almost guaranteed to not work I almost exclusively use FDroid, it's an amazing project. But I've never seen an app with so many issues

hunter2_ 4y ago
Agreed. I wonder if it falls into traps that simply didn't exist in the past, and release notes about breaking changes regarding those increasing blurry-but-not-killed modes were ignored.
abdullahkhalids 4y ago
Every few months, the app starts to crash constantly. Meaning, I open it, it crashes, then for some reason starts up again on its own, crashes again, and the cycle continues. I usually have to restart my phone, uninstall the app, and reinstall again from scratch.
soiler 4y ago
Weird, I've never had an issue except with trying to open updates from the notifications dropdown.
- geokon 4y ago
  I think if you live close to their servers maybe most of the issues would not be noticeable. If the app downloads and installs while you have the app page open then it seems to go smoothly. From Asia, I always get DSL speeds and need to leave the app/phone open for an extended amount of time to download even the smallest app
  - 4y ago

eointierney 4y ago

Thank you! F-Droid is one of those projects that adds so much peace of mind and usability to my computational life. It is a must-have.

stefan_ 4y ago
Just used it again today when some service asked me to use one of these generic 2FA OTP token apps. It first recommended the Microsoft one but that one literally wouldn't work unless you accept transmitting usage data, for a kind of app that is both calculator-levels of complexity and uniquely ill suited to transmitting any data. Found something simple and perfectly good working on FDroid.

JaggedJax 4y ago

My F-Droid would not auto-update, attempting to manually get the update through the app refused to load at all, and downloading from their homepage gave me an old version. I had to download the specific version directly from their package page via a browser: https://f-droid.org/packages/org.fdroid.fdroid/ https://f-droid.org/packages/org.fdroid.fdroid/ This seems to have resolved the self-auto update issue I had as well. I can now see the F-droid client page from within the F-droid client itself. It's great to see F-droid client updates. The app can be clunky at times, but they are doing great work with maintaining the repo. I feel like a better client experience would draw in and keep more users, so every step in that direction is appreciated.

efreak 4y ago
> downloading from their homepage gave me an old version. This is because the FDroid website does not expose the latest version of apps. The website itself is a static Jekyll website, and I've never found any information to indicate that the app listings aren't part of that, apart from them being missing from the source repos (which they would be if it's generated from the index at runtime).
BlueGh0st 4y ago
For anyone else following these steps: Be sure to scroll down to click "Download APK" below the version that you want to download, and not the giant "DOWNLOAD F-DROID" button right above it. This was a bit confusing on mobile before I came back and scrolled down the page some.

Egoist 4y ago

My Client didn't receive the update even after refreshing the repository. I was able to get the new version by searching for F-Droid and going to the "versions" section and click update on the latest version

deleted 4y ago
[deleted]

pserwylo 4y ago

Congratulations team. I was involved in the project for quite some time years ago. Indeed I ported the original “Read the full index.xml into Java memory using a giant DB class” with the first “Stream entries from XML into the database, and make use of ContentProviders” because they seemed like the “Android way to do things” at the time. I also worked on the migration from XML to JSON metadata. At the time this was done, we needed to updated the metadata format to support internationalisation of metadata and the inclusion of images. To see Torsten and others working on replacing my crufty-passed-their-use-by-date ContentProvider code with a modern Kotlin + Room implementation is heart warming. If any of you are reading this, please accept my deepest sympathies for having to pull that code out and rework it - that is not something I would have enjoyed doing! It is even better that it all lives in libraries that other clients can adopt if they choose so they don’t need to reinvent the wheel. For those interested, yes, I am also responsible for writing the bulk of the code for the “new” (now several years old) UI in the offical client which often gets maligned on HN (and this thread is no exception). At the time I did my best to fight off edge cases and quirks of the Android system. F-Droid needs to ask Android which apps are installed and what their signatures are, then cross verify that with its own database to tell you whether updates are available. It also needs to know whether new apps have been installed outside of F-Droid since last time you opened it, etc. It also needs to pass downloaded .apk files to the system and request for them to be installed, then wait for confirmation from the system. The API’s Android provide for this kind of work, but they always seemed flakey, unwieldily, and slow to respond. The whole experience is full of race conditions, and each bistro seems to handle it ever so slightly differently. I am still proud of how much we managed to achieve, and I’m also very pleased with the fact we were able to do so much great work around internationalised metadata, screenshots, encouraging donations to app developers, etc. But I’d be lying if I said I wasn’t still a little disappointed that I couldn’t iron out all of the kinks. Life circumstances meant that I drifted away from the project and no longer contribute (other than via Liberapay donations to the wonderful fdroiddata team). However I would love to revisit the project in the future to see if I can address some of those edge cases to ease the user experience for all of us. You may have noticed that for such an amazing project, used by many people (not just the client, but the entire infrastructure), there has been comparatively few contributors. Despite that, I am still extremely fond of the value they bring to the Free and Open Source ecosystem.

andyonthewings 4y ago

I found that my fdroid has not been updated to the latest release mentioned in this post (1.16). I opened it and pulled down to refresh, but it didn't show any available updates to fdroid. I opened the fdroid info page in the app, and at the bottom I saw 1.16.1 was available but 1.15.6 (the installed version at time) was labeled “suggested”, not sure what that meant. I selected 1.16.1 and it installed and ran smoothly anyway.

deleted 4y ago
[deleted]
pbhjpbhj 4y ago
Same behaviour for me, but I chose not to install. I like to wait a while (couple of weeks at least) unless critical security bugs are indicated.

RicoElectrico 4y ago

It shouldn't need to download the whole repo index for a mobile app store. It's a flawed assumption to begin with.

blendergeek 4y ago
Offline search and metadata is a really nice feature to have. I'm glad it is present and I'm happy to see it being improved rather than abandoned.
Aachen 4y ago
I've got mixed feelings about that as well, but on the whole it's about even and I'm not sad that the search is local and instant. It's not that big a deal to me to download a few megabytes on top of the f-droid apk. Then again, to download anything (including screenshots and other app info, let alone the app itself) you need a server connection so it's only mildly useful to not have to ask a server. And the search algorithm is... nonexistent I think is the most correct word to use. You get what you ask for. The top three hits for "camera" are Telegram and two identical looking SIP clients, of course. (There's not being influenced by algorithms and there's this.) I wonder if te project would accept a better algo if I'd contribute one; I've made one before at work for a not dissimilar dataset so I have some notion of what works, though it's not rocket science anyway.
notepalf 4y ago
I believe the whole repo is also used to check available app updates
jeroenhd 4y ago
It's not strictly necessary, but if the entire repo can fit inside 8MiB of compressed data I can understand why they chose this rather than server-side search. That's "three clicks on Twitter" in terms of data, not exactly the end of the world, though less is always better. F-Droid's main servers are always overloaded anyway, so just sending a nice and cacheable compressed archive seems like a fine trade-off to me.
- 4y ago

TrueSlacker0 4y ago

"Updating only what has changed" So... An rss feed?

JustSomeNobody 4y ago
More like a patch.

lenkite 4y ago

Why not just use a SQLite db ? Far more size efficient than JSON.

IshKebab 4y ago
Exactly my thoughts. JSON is totally the wrong format in the first place.
- eighthave 4y ago
  JSON is the file format, it is then parsed and stored in the local SQLite

tommica 4y ago

F-droid is an amazing project, and I am so glad it exists, because there are so many useful apps that people have made there that make my phone experience enjoyable.

franky47 4y ago

> stronger digest algorithm for repository signing: We now use SHA256 instead of SHA1 for the index signature Neither SHA-1 nor SHA-256 are signing constructs, they are hash functions. They provide integrity, not authenticity. For this kind of thing (a central authority signing and public clients verifying), you'd need a public key signature scheme, like ECDSA or EdDSA.

kapep 4y ago
> Neither SHA-1 nor SHA-256 are signing constructs, they are hash functions Well that's why they said "stronger digest algorithm". As far as I understand, the repository index is hashed (now using SHA-256 instead of SHA-1) and this hash is then signed as usual, using whatever public key signature scheme they are using.
bheadmaster 4y ago
The usual process of signing a bunch of data is to hash it and then encrypt it with public key encryption, so the hash function is as important as the public key encryption scheme. If the hash is weak, an attacker may be able to construct compromised data that hashes to the same hash, and the whole signature becomes worthless.
dspillett 4y ago
It isn't common to encrypt or sign the full content using asymmetric encryption. For encryption you usually pick a large random key for symmetric encryption, encrypt the body with a strong symmetric cypher and that key, and encrypt the symmetric key with your asymmetric method and the intended recipient's public key. For signing, you use a suitable secure hash function to produce a digest of the content, when sign the digest using your private key. Choice of digest function is as important as your choice in encryption method as an exploitable issue that allows you to generate the same digest for different content means that the signature, while secure in itself, is worthless because what has been signed is no longer effectively deterministic. tl;dr: So when they say “digest algorithm for repository signing” they don't mean that they are using the SHA256 result as a signature, but that they use SHA256 to generate the digest that is then signed.

eska 4y ago

Because of perf/size issues they switched to JSON..? What were they using before?

guntherhermann 4y ago
XML?
benibela 4y ago
JSON Looks like they switched from downloading the entire JSON on updates to downloading a patch

hydroid7 4y ago

Thank you f-droid for having a consistent UI since years.

pbhjpbhj 4y ago
Consistency is good. But I find the update flow to be annoying. Touch 'updates' tab, doesn't show you the updates until you pull down (with no affordance), update are summarised but not listed in the big space for updates to be listed, "update all" then doesn't update all but instead lists the updates in that big space, tap "update" on each item listed, you get a popup asking if you want to update it (because the two previous choices of "update", after already going to the update tab, might have been a mistake?). I appreciate it, but it's a weird flow. I'd expect touch "update" tab would run the "check for updates" without needing the pull down (maybe set a cache-time in settings); "update all" would do all the updates without any other taps (or with at most one [per app]).
- eighthave 4y ago
  Interesting points, I agree the Updates tab could do better there. Update All is implemented if you have F-Droid Privileged Extension installed, it could also be implemented when it is directly installed, if someone wants to contribute there.
- llanowarelves 4y ago
  Not being able to update multiple at once is an android security thing isn't it?
  - pbhjpbhj 4y ago
    Maybe, Google Play can do "all updates", but they maybe do shenanigans.

1vuio0pswjnm7 4y ago

The apps I get from F-Droid are generally not ones that will be frequently updated. In the case that there are updated versions available, I prefer to look at the source code changes before making a decision to update. (That, to me, is the benefit of F-Droid: Android apps with source code available.) As such, I do not use the F-Droid client app. I prefer to download the apks from the F-Droid site myself.

bheadmaster 4y ago

I'm really glad this is fixed. I like to make a point of keeping my software up-to-date, but waiting for F-Droid to download/uncompress/analyze the repository index has annoyed me so much I've stopped doing it whatsoever, unless I make a conscious decision to actually do it and invest time time.

kseistrup 4y ago

I gave up using the F-Droid app a long time ago. I tried a few alternatives and settled for Droid-ify: https://f-droid.org/en/packages/com.looker.droidify/ https://f-droid.org/en/packages/com.looker.droidify/