0

apt InRelease files update like twice every day, in ubuntu repositories and their mirrors. similarly in ubuntu and debian based distros, and other apt repositories. these files are small text files that contain hashes of other [fresh] text files, which contain hashes of [fresh] package files. and these files are signed. so, these files can prove that package has really come from the repository owner unmodified. this system is used automatically by the apt scripts on updating in order to prevent malware being installed in packages by third parties like network providers or mirrors ( they are "man in the middle" ) (and i think also can prevent from simple bit errors appearing).

but not only third parties, but also the repository owners themselves can install malware in packages, by intention, or by mistake, or their employees may do that, if they can sign the files.

licenses like gpl and bsd do not give any guarantee, and even licenses of proprietary/closed source/paid software, but state laws are still there. in case some user has found malware in package, they may need to check where from does it come and proof that in court. in case malware has come not by hacker attack, but from distribution repository itself, the apt system can be used to proof it. even before it is found where the malware has come from, it can be used in order to throw that version away (ie to proof that repository is not guilty).

but in order to proof that, people should prove that really that package was in the repository (ie on the server) on that date, on the time of update, and it was signed by the repository owner. for that, the fact should be somehow documented by third parties.

there are several possible ways:

  1. to check the inrelease file in https://web.archive.org/web/ and http://archive.li/ and other archives.
  2. to search for same files from other users of the repository.
  3. to search for same files in repository's mirrors' owners.
  4. maybe the inrelease files are saved in a blockchain?

inrelease files maybe saved by distribution itself. this is done by debian, see example. but it is not third party, in case of malware is installed by them by intention, such archive may be rewritten in order to hide the fact.

not only rewritten, it can be hidden immediately.

not only it can be "hidden immediately", but a malicious file may be sent only to a several/single user, in the process of update, (if repository owners think that the user is not going to catch them). third party archives are required also to prevent this. to prevent this, users should check, after apt update, and before apt upgrade, whether they has got the proper inrelease files, they are saved in /var/lib/apt/lists/, same as saved in one or several third party/independent/witness sites, (which must have [recently] downloaded the same file from other ips and with other cookies etc).

there are some ubuntu repository archives in archive.org. seems, this site is not used (by worldwide users of ubuntu) for this purpose: for example, there are only 31 captures of inrelease of bionic (18.04 lts), for now.

so, questions appear:

  1. if this is not used, then, how they, ubuntu users, do this? as i know, ubuntu is used by many big companies, for example, by wikipedia.
  2. and also, how this is done for other apt repositories? for example, debian's, it is also used by many big companies.
  3. how this problem is solved for systems other than apt, for example, rpm? i think answers to this are too big, so, answer to this part only if it does not take much space, like briefly or by links.

i think, the big companies and other users may do this:

  1. big companies may check sources and compile binaries
  2. they may use the repositories for binaries and trust them.
  3. they may use the repositories for binaries and archive inrelease files in some blockchain, about which i do not know.
  4. they may use the repositories for binaries and save all downloaded inrelease files in their local servers, and maybe also package files, and think that other repository users do same, hoping to use them as witnesses.
  5. like variant 2, they are not going to check source of malware, because they do not want to accuse them and go to court, because it requires too much effort. they just delete the malware or reinstall os and continue to work. if malware is installed by hackers, they are hard to catch, and probability of the case that malware is installed by repository owners is considered too small, because if they would do so, they are easy to catch (and then they lose their reputation, and may be jailed). but even if they are easy to catch, it is too much effort to go to court, and so, they just do not check this thing, as it is of low probability, and it can be said that they do not trust them. but the probability can be considered so low, only if they think somebody other checks all the binaries. maybe antivirus companies are doing this even with linux binaries?. if almost nobody check all binaries (mostly updates), simple users need to archive/witness/document these files.
  6. they may use some archive or pastebin sites to save InRelease files, and use proxy services in order to check that. but, as i see, the archive sites are not used for this. if they use pastebin, there is usually no way to browse or search them, as i know, so, the users should save links to the pastes somewhere, maybe in their local computers, or in the pastebin sites.

but i do not know surely, how do they do really, for that, i answer the question.

blockchain technology is better than the simple services like archive.org, and other single witnesses, because a single witness can, after a long time and work, find private key of the repository owner, by brute force attack, make malicious file and sign it by the key and put it in his archive/mirror and make false witness against repository owner.

by the way, there are the 2 free archive sites, which i know, and there are many free pastebin sites and many free proxies, and there is a free blockchain site to document small files: https://cryptograffiti.info/ , which uses bitcoin sv, but it does not save the inrelease file for free, because it is too big, out of limit (it is like 87 kilobytes).

by the way, i know about 2 sites to check blockchains' "firmness": Cost of a 51% Attack for Different Cryptocurrencies and are we decentralized yet?.

15
  • What is the question here? (All I read is a thesis about why you want to use blockchain as a source of proof. Possible but expensive). Blockchain in itself does not solve the problem listened (manipulation of signed data) because itself is just that. Signed data.
    – LvB
    Commented Sep 14, 2020 at 7:50
  • @LvB it solves the problem by threatening the plotter by punishment in future.
    – qdinar
    Commented Sep 14, 2020 at 7:57
  • But. Who is the plotter here? The repository owner? This is either yourself or a party you trust already. The packages themselves are also signed by a trusted party (usually the maintainer). And you can check all source changes if you like and only build packages from source. That’s a matter of effort V.S. gain. So how much is self building packages worth to you? I still do not see an advantage to using blockchain here. You could use it but I doubt it will add any information not know after the fact. (Especially if you have the infected machines data)
    – LvB
    Commented Sep 14, 2020 at 8:03
  • @LvB yes. whom of users do you think trust repository owner? can you give any example? maybe you mean ubuntu and debian users who use default sources configuration and do not check the inrelease files they get? i think they just do not have enough knowledge of security systems. i think, and they rely on wide users community, thinking that if so much users are using and trusting this, it should be ok to just install and use. but it is not. users who understand this should announce about this. and they announce, for example, this my question.
    – qdinar
    Commented Sep 14, 2020 at 8:44
  • @LvB checking sources and compiling are way too hard for a single person. especially checking the whole sources. checking only updates is also very hard, as i know, ie, even the changes are very big. material gains maybe different of different users. but the system i described is very easy. there are spiritual gains like feeling that you use a very secure operating system, so that even repository owners cannot hack it. this can give more inspiration to single developers to develop proprietary and saas software at their home computers, partially as secure as big companies do on their own dcs.
    – qdinar
    Commented Sep 14, 2020 at 9:09

0

You must log in to answer this question.

Browse other questions tagged .