Linux install - do not add "dropbox.list" to apt... (deb)

Despite there is no due date for the old format (not yet at least), it's good idea update to be performed on time! 👍

More information: here and here for instance.

Neal wrote:

... we have a built in command which will convert dropbox.list to dropbox.sources.

Hi Neal​,

I don't know what kind of command you have built, but your install still produces the old format. I just checked from the download page and select the newest deb file there. This file produces the old format still. The script (postinst) designed to install that information, residing there, is still the same (just a subset of that file I just downloaded):

....
REPOCONFIG="deb [arch=i386,amd64 signed-by=/etc/apt/keyrings/dropbox.asc] http://linux.dropbox.com/$DISTRO $REPO main"

          APT_GET="`which apt-get 2> /dev/null`"
          APT_CONFIG="`which apt-config 2> /dev/null`"

          # Parse apt configuration and return requested variable value.
          apt_config_val() {
            APTVAR="$1"
            if [ -x "$APT_CONFIG" ]; then
              "$APT_CONFIG" dump | sed -e "/^$APTVAR /"'!d' -e "s/^$APTVAR \"\(.*\)\".*/\1/"
            fi
          }

          # Set variables for the locations of the apt sources lists.
          find_apt_sources() {
            APTDIR=$(apt_config_val Dir)
            APTETC=$(apt_config_val 'Dir::Etc')
            APT_SOURCESDIR="$APTDIR$APTETC/$(apt_config_val 'Dir::Etc::sourceparts')"
          }

          # Add the Dropbox repository to the apt sources.
          # Returns:
          # 0 - no update necessary
          # 1 - sources were updated
          # 2 - error
          update_sources_lists() {
            if [ ! "$REPOCONFIG" ]; then
              return 0
            fi

            find_apt_sources

            if [ -d "$APT_SOURCESDIR" ]; then
              # Nothing to do if it's already there.
              SOURCELIST=$(grep -H "$REPOCONFIG" "$APT_SOURCESDIR/dropbox.list" \
                2>/dev/null | cut -d ':' -f 1)
              if [ -n "$SOURCELIST" ]; then
                return 0
              fi

              printf "$REPOCONFIG\n" > "$APT_SOURCESDIR/dropbox.list"
              if [ $? -eq 0 ]; then
                return 1
              fi
            fi
            return 2
          }
....

As you can see, nothing changed! This is the install script part that has to be adapted.

By the way, the last line of Verwijs​'s example in OP is bad idea to be kept too. When possible (i.e. the sign is used for single repository only - that's the Dropbox case), it's advisable the sign to be embedded in the .source file (something impossible in .list) - so instead of 2 files (dropbox.asc and dropbox.list) will be enough only 1 (dropbox.source) and this is considered more secure.

All the best!

Apologies Здравко​!

I misspoke, the one-line call is built into apt, not Dropbox:

sudo apt modernize-sources

I did some research into this format, and while Debian using it by default is new, it will still work with every version of Debian and Ubuntu we support.

Neal wrote:

I did some research into this format, and while Debian using it by default is new, it will still work with every version of Debian and Ubuntu we support.

Yes, it is valid still and will be to year 2029 at least (as described in documentation you have research did on). After that, despite not fixed yet when, the format may be stopped at any one moment. By the way, many other companies (like Microsoft, Oracle, etc.) have already moved their packages format to the new one. It's still not something urgent, but like many other things Dropbox will wait till old format becomes officially deprecated and dropped. 🤷 (i.e. when it comes up as something urgent)
And not only Debian uses it and it's not something new - Ubuntu uses it for ~3 years already as well as all other derivative distributions (check on all standard Ubuntu repositories 🙂 - can you see some .list there?!; I hope you wont check some too old unsupported release).

I hope you (Dropbox) won't rely users use any external commands (external to Dropbox) for Dropbox bugs fix! (including the one you posted) Would be a good idea Dropbox to "modernize" its packages, so additional modernization wouldn't be needed.

Hi again Здравко​!

This is the feedback I absolutely love to see on the Community!

I totally get it, addressing it before it becomes an issue and create less steps for the user. I've shared this thread and your detailed explanation with our team that handles Dropbox for Linux.

Hopefully this can be updated soon!

Hi Neal​,

I want to report something little more urgent related again to your repository organization. I just tried to update my packages and found out that there is a bug in your repository (files size mismatch). In your repository the sign file (actually all 'InRelease' files), for 2 of the files there, is declared incorrect size and so apt refuses to update package data for Dropbox. You may take a look on and compare InRelease and Release files. For InRelease, I enlightened following:

...
 137ac6101594668cfdb4bd6c3845c9aa             2030 main/binary-amd64/Packages
 62674c968547a6692c61aa2299346064             1164 main/binary-amd64/Packages.bz2
 4881108a0da15f24ca2612cf079f345c             1084 main/binary-amd64/Packages.gz
 5c903ce25ce9411b2c2fdb970e683b5b              677 main/binary-i386/Packages
...

The equivalent part of Release is as follows:

...
 a28570dbcd7eb36c2f08a3bc8aee7c1c             2030 main/binary-amd64/Packages
 33358b1ec1e381b7f83fff383a57eb3c             1177 main/binary-amd64/Packages.bz2
 dccf6ed1786f560ead5750b0ff0be2ee             1087 main/binary-amd64/Packages.gz
 e9e086c484c19d6543978720e41f9780              677 main/binary-i386/Packages
...

As you might saw already for files Packages.bz and Packages.gz neither hash nor size match, but it is MUST! Such differences (even one is enough) make the repository non trusted and apt responses with following:

E: Неуспех при изтеглянето на http://linux.dropbox.com/ubuntu/dists/noble/main/binary-amd64/Packages.bz2  File has unexpected size (1177 != 1164). Mirror sync in progress? [IP: 18.165.72.41 80]
   Hashes of expected file:
    - Filesize:1164 [weak]
    - SHA512:a50404036f1307dff23fca233e708773fd5be5413450c1dd61a5b5030b133f714edc1f2494c67665458ef07a13c45352dd485847a93014cf0c19fbb10a92a423
    - SHA256:eee63bb11431bf7a4345465c38a3912b914437468858765a326f91258bee6d1a
    - SHA1:4d5c4648c1e90426338f36c0f4604178caa92e59 [weak]
    - MD5Sum:62674c968547a6692c61aa2299346064 [weak]
   Release file created at: Thu, 08 Jan 2026 18:17:55 +0000

Whatever change you have done at 8 January, only Release has updated, but InRelease hasn't!

Even more - finally it's time to send in retirement weak hashing/signing algorithms and replace them with some more strong - something that as it seems apt complains about too.

This is not something that directly breaks the application, but keeping this will prevent further package update.
I hope after your forwarding this to responsible team they'll keep it into account from now on.

Hi Здравко​,

Thanks for reporting this issue too!

I've since passed this on to our team and they have confirmed this morning that they have now fixed the issue.

Thanks again and please let me know if you need anything else!