How to know which extension version is installed?

[Zlika]

Hi,

I cannot find a way to know which precise version of a given extension is installed. As *.tcz.info files are not downloaded by tce-load, it seems that there is no way to know which version was installed (to have some sort of traceabillity / configuration management). We can only know the version of TinyCore itself, using the "version" command.
Is there a way to know externsion versions?

Regards,
Thomas

[volkerp]

Hi Zlika,

tce-ab doesn't solve your problem?

[Misalf]

tce-ab or the info files only show which version is available in the repo. If you check the md5 files you can only tell if it's the same version or not, but not which one.
For this very reason I have hacked some tce-* scripts to always download and don't delete the info files.

[curaga]

There is no historical archive of versions/md5sums anywhere, so it's not possible to know how many versions were skipped. edit: or to download a certain old extension version.

You can download info files easily with the tce-fetch.sh command, "tce-fetch.sh binutils.tcz.info".

[Zlika]

Thank you for your answers.
That's definitively a big issue of the extension system. I hope it will be fixed in a latter release.
Downloading the info file is only a dirty workaround because:
* there is no way to download both the tcz and the info file in a single "transaction" (that means that the info file can change while we are downloading the tcz file)
* the info file is only for information purpose and does not really encode a clear, unique and consistent version number (different versions of the same tcz are often uploaded with the same info file)

Another big flaw of the way extensions are managed in TinyCore is that there is no clear link to the source code that was compiled to produce the tcz binary, so it is not possible to recompile the extensions from sources by ourself, or check that no backdoor was introduced in the extension. For example, I provided the openjdk-8 extensions, and nobody asked me for the source code! It amazed me, because I read an article from the original author of TinyCore saying that extensions were always built from sources and that no binary extension without source code was allowed: that's simply untrue.

I am concerned of the security implications of all these points.

[Juanito]

..there is no clear link to the source code that was compiled to produce the tcz binary, so it is not possible to recompile the extensions from sources by ourself, or check that no backdoor was introduced in the extension.

Our intent is that all of the extensions source and build instructions/build script are placed under the src folder for the repo in question - this is true for the majority of extensions.

I provided the openjdk-8 extensions, and nobody asked me for the source code

The extension making section of the wiki says, under the required files section, "If the source is under the GPL license, include the source as well".

[andyj]

I know for the extensions I maintain I always use a script, which is submitted along with the extension and source code. No manual work, the script starts from a clean source tree to the finished extension. But the problem you pose is true of every binary on the internet: How do you prove the binary is the legitimate compliation of the source that it is alleged to come from? Other than inspecting the source code yourself and compiling it yourself there's always a step (or leap for closed source) of faith.  And don't forget to check the source code for the compiler, there have been occurances of compilers compiling in their own back doors.

[curaga]

Storing every extension version would increase the space usage several times over, I'm afraid.

* there is no way to download both the tcz and the info file in a single "transaction" (that means that the info file can change while we are downloading the tcz file)

Even if tce-load had an argument to do so (patches welcome btw), this would still be possible, as the files are separate. When they are updated on the server, there is a possibility you download exactly between two "mv" commands, etc.

[Zlika]

I think some minor improvements would be beneficial for the project. Here is my proposal, feel free to discuss:

• All the extensions should have an automatic build script. One of the first step of the script should be to checkout a given commit from the project's github/bitbucket/sourceforge... repo. This way there would be a clear link between the generated binary and the source code (and there would be no need to store the source code). These build scripts should be hosted on the tinycore site. This is already the case for some extensions, but definitively not for all. It should not be possible to deploy a tcz without its build script. The side advantages is that it will be extremely simple to update a tcz or even to rebuild the entire repository for a new tinycore version.
• The tcz format should be updated to include a version number (not the full tcz.info file, that would increase the size for no reason, just a simple version id for a few bytes).
• To identify different versions of the tcz based on the same source code, a "-x" suffix could be used in its version string as in Debian.
• It should not be possible to deploy on the tcz repository two tcz that have the same version (instead increment the -x suffix).
• md5 is completly deprecated and unsafe to use nowadays, it should be considered to use sha256 (even if it means a little bit more space used to store the hash).

[gerald_clark]

Extensions are user submitted.  There is no central source or authority
Any build scripts will be those supplied by the extension submitter.
The guidelines are simple, and covered in the wiki, which is also user maintained.

[Zlika]

I think you missed my point. Of course extensions are user provided, and there is some wiki material describing the publishing process. The goal of my proposal was to address some big problems I had using TinyCore and submiting extensions:
* as far as I know, the submiting process does not enforce the submission of the build script. I already published several extensions without providing the build script (but as I try to do things right, I put the URL of the build script in the info file).
* the consequence of the previous point is that build scripts for most extensions cannot be found. I already had to write the build script of an existing (but buggy) extension from scratch, wasting hours of my time for nothing.
* everybody can submit binary extensions: we have to pray that no intentional vulnerability, backdoor or virus is introduced in the extensions. This will blow to the face of tinycore sooner or later.
* once a tinycore system is installed and running, there is no way to know the exact version of the extensions, so there is no way to do configuration management or to check if we are impacted by a CVE.

[curaga]

Source code must be stored in any case, the GPL requires that. It does not allow linking to a different server, that server could go down and then you don't have the source.

Numeric versions and fixed-format build scripts would be nice, but storing old versions would use too much space. Md5 clashes don't really matter, this has been discussed previously: the tcz must be a valid squashfs file, and the altered executable must be valid too. Squashfs is compression, you cannot change random bytes in it without consequences.

Build servers and CVE announcements would require significant manpower. It seems to me you're describing Debian; why not use Debian in that case?

[Zlika]

It seems to me you're describing Debian

Well, yes and no. There is a huge space between no configuration management at all and high level quality distrib like Debian, I was just proposing very minor and simple changes to move the cursor from "nothing" to "a little".
I also use Debian, but you cannot use a bicycle and a monster truck on the same roads :-)

[Zlika]

but storing old versions would use too much space

And by the way, this was not in my proposal. It's ok to keep only the last version on the server, but I want a way to know which version I have installed locally, so I can use the info file to know what are the major differences between my version and the one on the server.

[curaga]

Isn't that already possible via the time stamp?