Links skipped on HTML import

[smaragdus]

I encountered a problem while trying to import HTML bookmarks- some links were skipped. I will try to explain the problem below.

In one of the imported folders there are 6 links with the same name:

• Webpage archive
  https://archive.fo/

• Webpage archive
  https://archive.is/

• Webpage archive
  https://archive.li/

• Webpage archive
  https://archive.md/

• Webpage archive
  https://archive.ph/

• Webpage archive
  https://archive.vn/

When I imported the HTML file to LinkHub I saw that only one of these 6 links were imported (the last one, .VN domain). I find it strange since several browsers were able to successfully import this HTML file with all its folders and links, including all 6 Webpage archive instances, which means that the HTML file is not defective.

Can you try to reproduce this problem? If needed I can provide the HTML file.

By the way I would like to ask- why LinkHub is no longer updated on F-Droid? Is there any special reason for that (as I noticed there was no longer a link to F-Droid on your repository) or it is just a delay?

I will open several more issues. I considered whether it is appropriate to open new issues or list all of them here but I decided to open separate issues for better readability since different problems would be addressed.

Regards

[AmrDeveloper]

By the way I would like to ask- why LinkHub is no longer updated on F-Droid? Is there any special reason for that (as I noticed there was no longer a link to F-Droid on your repository) or it is just a delay?

TBO, I don't know, nothing has changed, I think, related to the config of F-Droid.

@IzzySoft, not sure if anything needs to be updated in this direction 🤔

[IzzySoft]

No idea, not being active there (enough to do with IzzyOnDroid). Want the app back with us?

[AmrDeveloper]

Want the app back with us?

@IzzySoft, Feel free to add it to the other repo :D, I will try to investigate the F-Droid issue

[IzzySoft]

Small finding by our scanners:

SigningBlock blobs:
-------------------
0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

can easily be avoided by adding some lines to your build.gradle:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs (for IzzyOnDroid/F-Droid)
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles (for Google Play)
        includeInBundle = false
    }
}

For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. in our documentation on Signing Block Checks at our website, and in our blog article Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.

Also, gradle hash is missing in your gradle/wrapper/gradle-wrapper.properties (our verifier will take care for that, so that's mostly for your own builds). But, the APK at your release was NOT built from the tagged commit:

     XML ELEM START [lineno=2, name='manifest', #attributes=7]
-      ATTR: http://schemas.android.com/apk/res/android:versionCode=42
-      ATTR: http://schemas.android.com/apk/res/android:versionName='2.0.6'
+      ATTR: http://schemas.android.com/apk/res/android:versionCode=41
+      ATTR: http://schemas.android.com/apk/res/android:versionName='2.0.5'
       ATTR: http://schemas.android.com/apk/res/android:compileSdkVersion=36

Though it claims 20b3145 – which we just built from as well. So it must have been a dirty tree with local, uncommitted changes – which were only committed after the build and the tagged commit, with 3c14f5f Could you, for future releases, take care the APK was built "from a clean tree at the commit the tag points to" (aka "first basic rule for RB", see our RB Hints for Developers)?

But even with the commits adjusted, classes.dex shows huge differences. Could have been artifacts from prior builds in the tree. Could you provide an APK built from a clean tree at 3c14f5f for us to cross-check (or if a new release is pending, include the above adjustments to get rid of the blob before you release, and we check that)? We use Reproducible Builds to ensure APKs have really been built from the indicated source, as security measure. Diff from the current build: diff.zip

Thanks in advance!

[AmrDeveloper]

Thank you @IzzySoft,

I will address those points and read the docs