Update README.md - Githubissues

Poussinou commented 1 year ago

Hi,

This small PR adds a button to get your app on F-Droid and removes the one leading to IzzyOnDroid repo, as your app is now in the official repo. You can later add a button for Google Play the same way : [<img src="https://play.google.com/intl/en_us/badges/images/generic/en-play-badge.png" alt="Get it on Google Play" height="80">]()

It also adds a link to get the latest APK from the Releases Section.

You can now eventually add the fdroid and/or f-droid tags that will appear on the right side of the repo.

Bnyro commented 1 year ago

Thanks you!

One thing: could we please keep the IzzyOnDroid badge as well? I'd love to keep Wall You and Translate You available in Izzy's repo, since these two can be affected by breaking API side changes so that quick updates are of advantage.

@IzzySoft, would that be okay with you?

IzzySoft commented 1 year ago

Marked for keep on my end now, as you thereby requested – so yes :smiley:

Bnyro commented 1 year ago

Thank you @IzzySoft <3

IzzySoft commented 1 year ago

Gladly :smile:

Bnyro commented 1 year ago

I've added the badge in https://github.com/you-apps/WallYou/commit/a5174a3b8b74f0e91477a3ba4500630ea862c087, thanks for the PR!

One question @IzzySoft and @Poussinou: I moved all the apps that where previously located under https://github.com/Bnyro to https://github.com/you-apps. Does F-Droid automatically follow the GitHub redirects to the new organization, or do I need to create a PR at the F-Droid repo for changing the links?

And if changes are needed in the IzzyOnDroid repo, could you please take care of that Izzy?

Thanks for all your help!

IzzySoft commented 1 year ago

See https://gitlab.com/fdroid/fdroiddata/-/merge_requests/13553 for example (that's the one I've already caught). Thanks to the redirect it still works without, but will mean additional network requests on each check which can be avoided.

TL;DR: If you could list all the applicationIds affected, I'd go over their corresponding *.yml files and fix it for you. For F-Droid's as well as for my repo.

Bnyro commented 1 year ago

Great, thank you! <3

The affected app ids are

com.bnyro.translate
com.bnyro.clock
com.bnyro.trivia
com.bnyro.wallpaper
com.bnyro.recorder
com.bnyro.contacts (which you already changed :))

IzzySoft commented 1 year ago

https://gitlab.com/fdroid/fdroiddata/-/merge_requests/13555

I also added the Translation links where missing. Thanks!

PS: Same of course for those of the apps which are still in my repo :wink:

Bnyro commented 1 year ago

Hey, unfortunately I need your help again.

I've been deleting the wrong folder accidentally (and my backup failed to sync), and now the key that has been used to sign all the "You" apps on this organization has been gone :/

Certainly, there's no way to recover that keystore file, so the next releases will have to be signed with a different key. Therefore users will also need to reinstall the app on the next update, iirc.

Is it possible that the repos F-Droid and IzzyOnDroid show a warning that users should backup important data in the app? And will F-Droid and IzzyOnDroid be able to publish updates for the "You" apps as usual, or fail because the signing key has changed?

Cheers

IzzySoft commented 1 year ago

Now, that's a worst-case-scenario. 2 parts. First, for the warning:

For my repo, you can update the app descriptions (wherever you use Fastlane) and let me know the applicationIds of the apps where you did that, so I can manually trigger an update for that. This does not work with F-Droid.org, as Fastlane is pulled with the builds – which means only the next build would show them. Which, wherever reproducible builds have been established, will fail and need manual adjustment.

So second, the updates. In both places, F-Droid.org and here, AllowedSigningKeys: needs to be adjusted. At F-Droid.org it's probably the best to add the new one, so previous reproducible builds stay valid. Same could be done with my repo, though here it might be better to simply replace it and remove older versions.

Now comes the tricky part, and of course no offense meant: How can we assure it's really you, and not someone who got access to your Github account? Obviously, you cannot provide a new APK signed with the old key (where only you should know the passphrase to). We don't have a previously proven GPG/PGP key for a signed confirmation mail either, so we cannot really make sure here, can we? But at least a "weak assurance" could be achieved. Let's see.

Bnyro commented 1 year ago

You could also ask @M00NJ or @matchboxbananasynergy to confirm my identity additionally, or the Mastodon account bnyro@mastodontech.de which is followed by the official LibreTube Mastodon account. Otherwise not sure how to confirm my identity, (apart from email which we already have done now).

At least that teaches me to make more backups of the keys next time, I'm very lucky I still had a backup of the LibreTube signing key because I once sent it to an other LibreTube contributor.

The application ids affected are

com.bnyro.translate
com.bnyro.clock
com.bnyro.trivia (but probably doesn't need to be changed it got archived/discontinued)
com.bnyro.wallpaper com.bnyro.recorder
com.bnyro.contacts

So the procedure would be to create a new key, and get the signatures from an apk built with it?

IzzySoft commented 1 year ago

Thanks! Confirming mail exchange via Tutanota, so we have a "weak assurance" at least. If you know a way to solidify that, it would of course be welcome. (ah, crossed) Good idea: send me (and fdroidorg at the same instance) a DM then. For the latter you can also mention our mail exchange as second confirmation. If the two referenced people could confirm here as well, that would lend the entire thing some more weight, too.

So I'd have to ask you to open an issue with fdroiddata for your app listings there (just those having reproducible builds enabled, as the others will continue fine for they are signed by F-Droid, and other than with my repo, AllowedSigningKeys is not enabled for all other apps (in my repo it's enabled for all apps now, as it relies on the APKs provided by the developers).

Prepare the Fastlane accordingly then, please, and let me know which I should have updated then. The failed updates in my repo I'll then deal with when they show up.

(updating as our comments just crossed)

At least that teaches me to make more backups of the keys next time

That cannot be emphasized enough, right. Ideally have a copy on at least an external medium only connected for the sake of making backups to it, plus one in a physically different place.

So the procedure would be to create a new key, and get the signatures from an apk built with it?

No need to re-sign older releases. But yeah, you'd need to create a new key to be used with future ones.

Are the mentioned applicationIds ready for the Fastlane pull? Just let me know when I shall trigger it then.

M00NJ commented 1 year ago

I can confirm that @Bnyro has been talking to me about the lost keys on matrix. This should put more weight behind his claim, since it would mean that a potential impersonater would have to have gained access to his matrix account as well. I can provide a screenshot of the conversation if needed.

IzzySoft commented 1 year ago

Thanks! That should be sufficient weight I'd say. At least for me. The issue for fdroiddata will still be needed, and can link here for background.

Bnyro commented 1 year ago

I've opened an issue at Fdroid-Data here: https://gitlab.com/fdroid/fdroiddata/-/issues/3056.

The Mastodon private messages should have arrived too (I'm actually not too sure about that since I don't use Mastodon much, if needed please tell me to send it again or differently.)

com.bnyro.recorder and com.bnyro.contacts have a warning to create a backup in the full_description.txt now, for the other apps making a backup is not important since they don't save any important data. It would be great if you could pull them with the next update (or now already).

Bnyro commented 1 year ago

com.bnyro.wallpaper received a new release with the new signing keys here: https://github.com/you-apps/WallYou/releases/tag/v5.0.

Aaaand, made some backups at different places and sent the keys to other contributors that I trust :joy:

IzzySoft commented 1 year ago

OK, then today's update will take care for that. Automatically in the sense that Fastlane will be updated but the new APK not be accepted – so for whoever has the app installed will get the notification (as the signature still matches then, F-Droid will show the app as installed).

Once I move out the APK, the update will show up but the app won't be shown as update. So I'll make an exception here, adding the new hash (instead of replacing the existing one), so the two can co-exist and allow for the hints to be shown as well as for the new release to be installed (after removing the previous one). We shall do that for the other apps then as well, as soon as their updates show up. I'd add a note to the metadata here then to remove the old hash as soon as the last version using it is gone.

That OK with you?

Need to see how it will be handled at F-Droid.org, as there "old versions" remain in the archive. No procedure in place yet for that, as AllowedSigningKeys is a rather new feature and affected this way for the first time now.

Bnyro commented 1 year ago

OK, then today's update will take care for that. Automatically in the sense that Fastlane will be updated but the new APK not be accepted – so for whoever has the app installed will get the notification (as the signature still matches then, F-Droid will show the app as installed).

That seems to be a good solution :+1:

Once I move out the APK, the update will show up but the app won't be shown as update. So I'll make an exception here, adding the new hash (instead of replacing the existing one), so the two can co-exist and allow for the hints to be shown as well as for the new release to be installed (after removing the previous one). We shall do that for the other apps then as well, as soon as their updates show up. I'd add a note to the metadata here then to remove the old hash as soon as the last version using it is gone.

That OK with you?

That's perfect, thank you!

Need to see how it will be handled at F-Droid.org, as there "old versions" remain in the archive. No procedure in place yet for that, as AllowedSigningKeys is a rather new feature and affected this way for the first time now.

Okay, so I'm the first one to test that - interesting :p

I've really been a bit frustrated when I figure out the signing keys are gone, so you're help came perfectly right.

Thanks for your fast help on all that! :heart:

IzzySoft commented 1 year ago

interesting

Eh, the old Chinese curse, huh? "May you live in interesting times…" :see_no_evil:

Thanks for your fast help on all that!

Gladly given! And as bad as the situation is, it shows us…

to take better care for… err, addressed already :zany_face:
we need an established procedure for that (working on it; for now it's what I've outlined above)
it's a lot of fuss
we don't want to have that happen too often :see_no_evil:

Bnyro commented 1 year ago

"May you live in interesting times…"

Certainly, it's going to be interesting what happens next :)

to take better care for… err, addressed already :zany_face:

Unfortunately, I also lost some other important personal data - that'll be enough of effort to restore as well, e.g. some application papers, CVs, ... Luckily, I still had a backup of some of them on a different machine. From now on, everything will be backed up multiple times :)

it's a lot of fuss

Especially to confirm you're the real maintainer and not an impersonator - but not really sure how that could be done differently

IzzySoft commented 1 year ago

There are things like "undelete" – if you know how and the data was not yet overwritten.

but not really sure how that could be done differently

We could have e.g. GPG/PGP public keys stored on our end. Hopefully, the corresponding private keys are not lost along then. And different kinds of contact ways, as not all accounts are affected at the same time (hopefully). Which is what helped us here.

From now on, everything will be backed up multiple times :)

Good! And best luck for recovery of the other documents!!

Btw: Might help to mention the affected version in your full_description.txt ("before updating the app from version x or below") – so it's clear if one can safely ignore the message. You will have to keep it there for a while.

Bnyro commented 1 year ago

There are things like "undelete" – if you know how and the data was not yet overwritten.

I tried that - I ended up with 400GB of data, but unfortunately I couldn't find the important part of it :/

We could have e.g. GPG/PGP public keys stored on our end. Hopefully, the corresponding private keys are not lost along then. And different kinds of contact ways, as not all accounts are affected at the same time (hopefully). Which is what helped us here.

True, that makes sense. Though I'm certain I would have stored GPG/PGP keys in the same folder as the keys, so it probably wouldn't have helped in my case. Good! And best luck for recovery of the other documents!!

Thank you! <3 Btw: Might help to mention the affected version in your full_description.txt ("before updating the app from version x or below") – so it's clear if one can safely ignore the message. You will have to keep it there for a while.

Oh, true, I didn't think about that. But it's probably sufficient to add the version when creating the next release, since the most recent version is affected, so it's fine for now.

IzzySoft commented 1 year ago

I tried that - I ended up with 400GB of data, but unfortunately I couldn't find the important part of it :/

Did you make a backup of that partition to a different disk/partition to further try? And how did you try to find things? Best approach is usually:

shut down/remount the disk/partition read-only
make an image of the affected partition
make a copy of that image and try recovering from there (e.g. using TestDisk). Should you break the image while trying: start over with a fresh copy

So right after step 2 was completed, you can continue using the disk/partition normally when needed. And you can continue the recovery tries as long as needed (and as long as you see any sense in that).

Oh, there's also extundelete should you be on Linux with ext3 or ext4, which uses the journal to find and restore files accidentally deleted.

But it's probably sufficient to add the version when creating the next release

You can place those details into the release notes / per-release-changelogs, true. That allows you to put the same phrase for all apps, pointing to the release notes for details. Which would also keep the app description from being bloated while still providing sufficient details.

Bnyro commented 1 year ago

Thanks for your help :)

Unfortunately, I don't have any unused disk I could use to create a backup of my current disk, so that's not possible. What I did is using photorec (which is basically testdisk without shutting down if I get that correctly) to recover the data (I use an ext4 partition), without shutting the PC down. It really restored a lot of data, so that's been quite impressive.

For trying to rescue the signing keys, I have been iterating over all *.jks files and tested my password and key alias on it, unfortunately keytool printed an error message that there's something wrong with the file for each of them.

Most of my important files are stored as pdf, so I have been looking at *.pdf, but it only found some handbooks of Linux programs and other similar useless stuff. I haven't edited these pdf files for a while now, so maybe they're just not recoverable anymore, no idea.

IzzySoft commented 1 year ago

I see. Still worth a try using extundelete. Cannot hurt. Maybe something's still left in the journals. If not, you at least won't ask you the following years if it might have worked :wink:

IzzySoft commented 1 year ago

You forgot to put the note on Wall You. New version was pulled, but there were no Fastlane updates. Checking the code, I see none either. Added the new signing key to the white list, but the note should be there once it goes life. Can you please…?

Bnyro commented 1 year ago

I only added the note to apps that require creating a backup - so if you think it makes sense to add it everywhere I'll add it here too.

Bnyro commented 1 year ago

full_description.txt is updated with a note on it now :+1:

IzzySoft commented 1 year ago

Thanks – and as you see fit! Pulled in the Fastlane for Wall You, so everything ready. Remember there's no need for this procedure for those apps without RB when installed from F-Droid (i.e. those APKs signed by F-Droid, as there the signature hash won't change).

IzzySoft commented 1 year ago

PS: for "being first", Wall You was the first app with 2 AllowedSigningKeys in my repo. So thanks for confirming that works :see_no_evil:

Bnyro commented 1 year ago

Perfect, thanks! If I remember correctly, all apps use reproducible builds - that's the problem.

IzzySoft commented 1 year ago

Ah, right – Trivia is no longer updated (I just remembered there was at least one without RB). All other com.bnyro.* are.

OK, so for my repo, I then simply wait for he other changed candidates to drop in. Should you want some Fastlane pulled before, just let me know.

you-apps / WallYou

Update README.md #113