Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New F-Droid repository format for faster and smaller updates

f-droid.org

Post reply on HN
Print view View original

101–110 of 146 posts

Re: New F-Droid repository format for faster and smaller updates

#101

Post by pbhjpbhj »

andyonthewings wrote: post #18

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 smoothl…

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.

Re: New F-Droid repository format for faster and smaller updates

#102

Post by pbhjpbhj »

hydroid7 wrote: post #80

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

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]).

Re: New F-Droid repository format for faster and smaller updates

#103

Post by franky47 »

dspillett wrote: post #94
franky47 wrote: post #68

> 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.

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 th…

Both ECDSA and EdDSA hash the message internally before signing. The only advantage of signing a pre-hash, other than convenience of computation (eg: if a streaming implementation of the internal pre-hash is not available) would be to allow checking integrity without authenticity, which makes little sense.

Re: New F-Droid repository format for faster and smaller updates

#104

Post by rakoo »

izacus wrote: post #99
rakoo wrote: post #70

Earlier quoted context omitted.

I don't won't to be tethered 24/7 to the internet to use my mobile phone. Data exchange isn't free, both in money and in environmental impact. That's a flawed assumption to begin with.

You're talking about an app store here though - by definition it needs to retrieve the app itself and assets related to each entry (e.g. screenshots), so it's not like you're achieving anything useful by downloading the database offline. This isn't something like a news reader.

It is useful to me. It allows me to search for apps while offline, and wait for non-metered data to actually download it; it's something I find myself using a lot

Re: New F-Droid repository format for faster and smaller updates

#105

Post by rakoo »

never_inline wrote: post #90
rakoo wrote: post #70

Earlier quoted context omitted.

I don't won't to be tethered 24/7 to the internet to use my mobile phone. Data exchange isn't free, both in money and in environmental impact. That's a flawed assumption to begin with.

On the other hand having to download all app details at once takes many MBs, not always fast. You can instead cache details of some applications. I think homebrew moved away from repository approach too.

I usually update repos while on wifi, then search, then use wifi again to download. I like the flexibility of not having to be connected, my phone has more than enough storage space to store a few MBs of repo database

Re: New F-Droid repository format for faster and smaller updates

#106

Post by dspillett »

franky47 wrote: post #103
dspillett wrote: post #94

Earlier quoted context omitted.

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 th…

Both ECDSA and EdDSA hash the message internally before signing. The only advantage of signing a pre-hash, other than convenience of computation (eg: if a streaming implementation of the internal pre-hash is not available) would be to allow checking integrity without authenticity, which makes little sense.

Perhaps they are using the hash output for quick corruption tests as well as signing for authenticity?

And if they are computing a hash for that anyway, the computation saving from signing the hash not the whole content might be worthwhile?

Re: New F-Droid repository format for faster and smaller updates

#107

Post by [deleted] »

franky47 wrote: post #103
dspillett wrote: post #94

Earlier quoted context omitted.

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 th…

Both ECDSA and EdDSA hash the message internally before signing. The only advantage of signing a pre-hash, other than convenience of computation (eg: if a streaming implementation of the internal pre-hash is not available) would be to allow checking integrity without authenticity, which makes little sense.

[deleted]

Re: New F-Droid repository format for faster and smaller updates

#108

Post by joemazerino »

geokon wrote: post #8

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 have never shared your experience with F-Droid. Buggy at times, sure, but overall a good deployment mechanism.

Re: New F-Droid repository format for faster and smaller updates

#109

Post by franky47 »

dspillett wrote: post #106
franky47 wrote: post #103

Earlier quoted context omitted.

Both ECDSA and EdDSA hash the message internally before signing. The only advantage of signing a pre-hash, other than convenience of computation (eg: if a streaming implementation of the internal pre-hash is not available) would be to allow checking integrity without authenticity, which makes little sense.

Perhaps they are using the hash output for quick corruption tests as well as signing for authenticity? And if they are computing a hash for that anyway, the computation saving from signing the hash not the whole content might be worthwhile?

Adding a pre-hash is the overhead here, because of the internal hash.

Granted, verifying only that hashes match for integrity would be cheaper than checking the signature. But since you need to to that anyway for authenticating the payload, why the intermediate step?

Re: New F-Droid repository format for faster and smaller updates

#110

Post by mcsniff »

hilbert42 wrote: post #39
geokon wrote: post #8

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%…

"...It's been years since the UI update and it's always been amazingly buggy" Being buggy is only one aspect, the other was the annoying change of UI that presents apps in rows of large, gawky icons instead of the previous efficient rows of title text each headed by a small icon (as say in Windows 'List' mode). Unfortunately, this leaves me stuck on ancient version F-Droid 0.102.3. When looking for an app this new la…

I quite like Droid-ify as a better front end for F-Droid, I don't even bother downloading the main client anymore.

https://f-droid.org/en/packages/com.looker.droidify/

Post reply on HN