GNU LibreJS detects some unlicensed JS #64

Ghost commented 2019年07月18日 19:59:28 +02:00

I didn't test every page, but some pages have some unlicensed JS.
The following JS was blocked by GNU LibreJS:

• https://codeberg.org/vendor/plugins/promise-polyfill/polyfill.min.js
• https://codeberg.org/vendor/plugins/highlight/highlight.pack.js

Fixing it is pretty easy, so I will go ahead and create a pull-request.

I didn't test every page, but some pages have some unlicensed JS. The following JS was blocked by GNU LibreJS: - https://codeberg.org/vendor/plugins/promise-polyfill/polyfill.min.js - https://codeberg.org/vendor/plugins/highlight/highlight.pack.js Fixing it is pretty easy, so I will go ahead and create a pull-request.

Ghost commented 2019年07月18日 20:50:36 +02:00

Hmm, I can't immediately see what's wrong.
The scripts are listed in the Javascript list.

Hmm, I can't immediately see what's wrong. The scripts are listed in the Javascript list.

hw commented 2019年07月19日 21:46:37 +02:00

Can you please keep us updated if you find out more?

Can you please keep us updated if you find out more?

Ghost commented 2019年07月19日 22:18:55 +02:00

Sure, here are some things which I noticed:

• The GNU website mentions that the JavaScript licenses link should have a rel="jslicense", which is currently missing on this website;

• I am pretty sure that MIT is not a valid license. It is not specific enough. The people of GNU prefer the term Expat or X11. Both of these are known as MIT, but the licenses are not the same. Expat is the one that people usually use;

• The polyfill JavaScript link does not seem to link to a JavaScript file. It links to a directory;

I couldn't seem to fix the specific issue locally, even with some changes.
I might look more into the issue. I am also not sure how that I exactly run this project locally, but I tried to play with some html code.

Sure, here are some things which I noticed: - The [GNU website](https://www.gnu.org/licenses/javascript-labels.en.html) mentions that the JavaScript licenses link should have a rel="jslicense", which is currently missing on this website; - I am pretty sure that MIT is not a valid license. It is not specific enough. The people of GNU prefer the term Expat or X11. Both of these are known as MIT, but the licenses are not the same. Expat is the one that people usually use; - The polyfill JavaScript link does not seem to link to a JavaScript file. It links to a directory; I couldn't seem to fix the specific issue locally, even with some changes. I might look more into the issue. I am also not sure how that I exactly run this project locally, but I tried to play with some html code.

hw commented 2019年08月01日 21:44:52 +02:00

Please ask all questions related to build-deploy-gitea (test), we know the documentation is far from perfect, and want to improve.

Please ask all questions related to build-deploy-gitea (test), we know the documentation is far from perfect, and want to improve.

Ghost commented 2019年08月01日 23:21:57 +02:00

I hadn't read the documentation yet. The createVM script seems to fail though. I currently don't have the time to setup a VM either.

I might try again during September.

The error is:
cp: cannot stat '/home/rmw/.ssh/authorized_keys': No such file or directory

I hadn't read the documentation yet. The createVM script seems to fail though. I currently don't have the time to setup a VM either. I might try again during September. The error is: ```cp: cannot stat '/home/rmw/.ssh/authorized_keys': No such file or directory```

hw commented 2019年08月02日 20:50:16 +02:00

This script line merely tries to copy your public ssh key onto the newly created machine, so that you can log in. the authorized_keys file is a common place for those, but finally mere heuristic, of course not everybody has this set up.

You can safely disable this line (or copy your public ssh key into this file).

This script line merely tries to copy your public ssh key onto the newly created machine, so that you can log in. the authorized_keys file is a common place for those, but finally mere heuristic, of course not everybody has this set up. You can safely disable this line (or copy your public ssh key into this file).

Ghost commented 2019年08月04日 00:19:03 +02:00

Hmmm, gitea has the same problem with the same scripts. I haven't checked all scripts, but the problems look alike. I think that it might be better to fix the issue there, so that it can be fixed for everyone who forks or uses gitea.

Anyway, I don't have much time to look into everything at the moment.
I should have more time during September.

Hmmm, gitea has the same problem with the same scripts. I haven't checked all scripts, but the problems look alike. I think that it might be better to fix the issue there, so that it can be fixed for everyone who forks or uses gitea. Anyway, I don't have much time to look into everything at the moment. I *should* have more time during September.

Ghost commented 2019年09月24日 14:21:14 +02:00

I haven't looked into this problem yet, but I will try to do so soon. Sorry for the late reply.

Edit: I receive the following error Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory when I execute the createVM.sh script.

I commented the .ssh cp in the script, since it does not run when I don't do that (see previous comment).

I have virt-manager installed. I don't have systemd on my OS, so I can't create the KVM if that service requires that. I use Devuan, so I use systemv.

Edit 2: I don't have the libvirt-daemon it conflicts with other packages. Is there another way to test this? I do have a working virtualbox if there are images available for that.

I haven't looked into this problem yet, but I will try to do so soon. Sorry for the late reply. Edit: I receive the following error `Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory` when I execute the createVM.sh script. I commented the .ssh cp in the script, since it does not run when I don't do that (see [previous comment](https://codeberg.org/Codeberg/Community/issues/64#issuecomment-4474)). I have virt-manager installed. I don't have systemd on my OS, so I can't create the KVM if that service requires that. I use Devuan, so I use systemv. Edit 2: I don't have the libvirt-daemon it conflicts with other packages. Is there another way to test this? I do have a working virtualbox if there are images available for that.

hw commented 2019年09月29日 21:30:16 +02:00

You can run the gitea binary after building native on the host without VM. Please check the Gitea documentation for the flags and environment variables needed to point to the config files etc; you can also look into the systemd service file for an example: https://codeberg.org/Codeberg/build-deploy-gitea/src/branch/master/etc/systemd/system/gitea.service

You can run the gitea binary after building native on the host without VM. Please check the Gitea documentation for the flags and environment variables needed to point to the config files etc; you can also look into the systemd service file for an example: https://codeberg.org/Codeberg/build-deploy-gitea/src/branch/master/etc/systemd/system/gitea.service

6543 commented 2020年12月03日 01:18:41 +01:00

Upstream issue: https://github.com/go-gitea/gitea/issues/13393

Upstream issue: https://github.com/go-gitea/gitea/issues/13393

wolftune commented 2023年12月30日 06:53:43 +01:00

Also, newer issue exists in the Forgejo issues forgejo/forgejo#1654

So, could be resolved at Gitea, Forgejo, or Codeberg levels, whatever is appropriate.

Also, newer issue exists in the Forgejo issues https://codeberg.org/forgejo/forgejo/issues/1654 So, could be resolved at Gitea, Forgejo, or Codeberg levels, whatever is appropriate.

wolftune commented 2023年12月30日 16:46:44 +01:00

I should add that this is one of the only issues blocking Codeberg from getting a better grade in the in-progress official GNU review of Codeberg for https://www.gnu.org/software/repo-criteria-evaluation.html

So, while I'd most like to see this resolved all the way upstream at Gitea (so that LibreJS works with all Gitea instances and derivatives), it would make a difference if Codeberg would just resolve it directly for now.

I should add that this is one of the only issues blocking Codeberg from getting a better grade in the in-progress official GNU review of Codeberg for https://www.gnu.org/software/repo-criteria-evaluation.html So, while I'd most like to see this resolved all the way upstream at Gitea (so that LibreJS works with all Gitea instances and derivatives), it would make a difference if Codeberg would just resolve it directly for now.

wolftune commented 2024年01月23日 20:21:21 +01:00

Although full LibreJS recognition is ideal, here's a proposed step in the right direction:

Make some appropriate web-labels page or similar, as in https://www.gnu.org/licenses/javascript-labels.html (see example: https://weblabels.fsf.org/www.fsf.org/CURRENT/ )

The goal in practice is that someone can get directed to the un-minified source files for the JS. So, even if LibreJS doesn't recognize it, some documentation that says "Codeberg uses these JS libraries" with links to the sources and licenses, that would facilitate people whitelisting Codeberg in LibreJS with confidence that they can indeed study what the JS is doing.

(Side-note: I personally trust Codeberg here and am not interested in such investigations, but I support best-practices and am passing on perspectives from others with whom I've discussed the issues around them trusting Codeberg)

Although full LibreJS recognition is ideal, here's a proposed step in the right direction: Make some appropriate web-labels page or similar, as in https://www.gnu.org/licenses/javascript-labels.html (see example: https://weblabels.fsf.org/www.fsf.org/CURRENT/ ) The goal in practice is that someone can get directed to the un-minified source files for the JS. So, even if LibreJS doesn't recognize it, some documentation that says "Codeberg uses these JS libraries" with links to the sources and licenses, that would facilitate people whitelisting Codeberg in LibreJS with confidence that they can indeed study what the JS is doing. (Side-note: I personally trust Codeberg here and am not interested in such investigations, but I support best-practices and am passing on perspectives from others with whom I've discussed the issues around them trusting Codeberg)

sthagen commented 2024年01月23日 21:09:04 +01:00

This example given in:

Make some appropriate web-labels page or similar, as in https://www.gnu.org/licenses/javascript-labels.html (see example: https://weblabels.fsf.org/www.fsf.org/CURRENT/ )

to me looks weird and I cannot even imagine how that should build trust that is not already given to the service.

Why not offer a software bill of materials in a recognized format like SPDX or CycloneDX or even SWID?

An SBOM tracing upstream is what I would expect from FSF service endpoints not a three column table with a few links pointing to some source without any license info included and some links not even resolving for the public (as eg. https://static.fsf.org/nosvn/modified-battleforthenet-widget/ which gives me an HTTP/403).

This example given in: > Make some appropriate web-labels page or similar, as in https://www.gnu.org/licenses/javascript-labels.html (see example: https://weblabels.fsf.org/www.fsf.org/CURRENT/ ) to me looks weird and I cannot even imagine how that should build trust that is not already given to the service. Why not offer a software bill of materials in a recognized format like SPDX or CycloneDX or even SWID? An SBOM tracing upstream is what I would expect from FSF service endpoints not a three column table with a few links pointing to some source without any license info included and some links not even resolving for the public (as eg. <https://static.fsf.org/nosvn/modified-battleforthenet-widget/> which gives me an HTTP/403).

fnetX commented 2024年01月23日 23:24:18 +01:00

some documentation that says "Codeberg uses these JS libraries"

The footer has a link below "Legal": Licenses. Is this what you have in mind or is something missing for it?

> some documentation that says "Codeberg uses these JS libraries" The footer has a link below "Legal": [Licenses](https://codeberg.org/assets/licenses.txt). Is this what you have in mind or is something missing for it?

wolftune commented 2024年01月23日 23:51:59 +01:00

@fnetX I am aware of that, and it has entries like brace-expansion@2.0.1 and licenses, but there's no link to source files

@fnetX I am aware of that, and it has entries like `brace-expansion@2.0.1` and licenses, but there's no link to *source files*

qrpnxz commented 2024年01月25日 05:10:25 +01:00

@sthagen SPDX is not evidently a suitable replacement. Web labels have three simple columns: object, license, source. I reckon SPDX may be suitable for the first two, but I don't find it is for the third (which is the main problem, since Codeberg already posts licenses.) I have not seen any website use it, so it is a strange suggestion. It is also a far more complicated thing to generate and consume.

@sthagen SPDX is not evidently a suitable replacement. Web labels have three simple columns: object, license, source. I reckon SPDX may be suitable for the first two, but I don't find it is for the third (which is the main problem, since Codeberg already posts licenses.) I have not seen any website use it, so it is a strange suggestion. It is also a far more complicated thing to generate and consume.

wolftune commented 2024年01月25日 05:31:46 +01:00

I got a reply at https://github.com/go-gitea/gitea/issues/13393 (which someone else opened way back in 2020)

The idea of searching npmjs.org for the JS files with associated versions at least is clear enough to be usable as a human workaround... I'm adding a comment there too. Maybe this can be at least improved upstream in Gitea overall.

I got a reply at https://github.com/go-gitea/gitea/issues/13393 (which someone else opened way back in 2020) The idea of searching npmjs.org for the JS files with associated versions at least is clear enough to be usable as a human workaround... I'm adding a comment there too. Maybe this can be at least improved upstream in Gitea overall.

sthagen commented 2024年01月25日 06:27:41 +01:00

@sthagen SPDX is not evidently a suitable replacement. Web labels have three simple columns: object, license, source. I reckon SPDX may be suitable for the first two, but I don't find it is for the third (which is the main problem, since Codeberg already posts licenses.) I have not seen any website use it, so it is a strange suggestion. It is also a far more complicated thing to generate and consume.

Well, SBOMs in SPDX and CycloneDX are the way to go then, as they provide a machine readable and openly standardized way for obtaining and following the exact coordinates for source, license, revision used, possibly all 3rd party included from the direct library used.

These "alternative" triplets of unrelated information as on that example web page are to me a strange way of building trust.

A publicly accessible bill of materials - esp. for an online service that may continuously update the effective components - is what builds trust. Esp. CycloneDX when using purl to locate the package of a component within the packaging namespace as nom, pypi, and others. is much clearer for the user who is really interested in the assembly of a service at any point in time.

The doable and the easy are not really a concern around these "libre" or "free as in x not in y" questions. Or are they?

> @sthagen SPDX is not evidently a suitable replacement. Web labels have three simple columns: object, license, source. I reckon SPDX may be suitable for the first two, but I don't find it is for the third (which is the main problem, since Codeberg already posts licenses.) I have not seen any website use it, so it is a strange suggestion. It is also a far more complicated thing to generate and consume. Well, SBOMs in SPDX and CycloneDX are the way to go then, as they provide a machine readable and openly standardized way for obtaining and following the exact coordinates for source, license, revision used, possibly all 3rd party included from the direct library used. These "alternative" triplets of unrelated information as on that example web page are to me a strange way of building trust. A publicly accessible bill of materials - esp. for an online service that may continuously update the effective components - is what builds trust. Esp. CycloneDX when using purl to locate the package of a component within the packaging namespace as nom, pypi, and others. is much clearer for the user who is really interested in the assembly of a service at any point in time. The doable and the easy are not really a concern around these "libre" or "free as in x not in y" questions. Or are they?

tusharhero commented 2025年04月02日 06:22:31 +02:00

This was also discussed at GNU Guix's Codeberg migration discussion.

https://mail.gnu.org/archive/html/guix-patches/2025-03/msg00156.html

This was also discussed at GNU Guix's Codeberg migration discussion. https://mail.gnu.org/archive/html/guix-patches/2025-03/msg00156.html