fajfer.org

Serwowanie stron z gita i bezpieczeństwo

Damian Fajfer — Thu, 19 Feb 2026 02:03:00 +0000

Przeczytałem kiedyś na Niebezpieczniku artykuł o wycieku w sklepie influencerki Wersow. Artykuł zainspirował mnie przede wszystkim do zainstalowania wtyczki DotGit, ale do tej pory nie udało mi się znaleźc niczego spektakularnie ciekawego. Ot, proste strony statyczne czy kod, który i tak jest publiczny. Do dziś wątpiłem, że ktoś na serio wrzuciłby kredki do gita na prywatne repozytorium a potem rzucał git pull do synchronizacji w tym samym repozytorium.

Wyprzedzając pytania - administrator został powiadomiony i wpis został umieszczony już po naprawieniu problemu.

Od .git/config do haseł

Serfując po internecie z wyżej wymienioną wtyczką dostaniemy popup o znalezionym repozytorium .git, adresy zbierają się też w samym narzędziu więc można co jakiś czas spojrzeć co udało się przypadkowo zebrać. Spróbujmy wyciągnąć z tego coś sensownego.



Poręczna funkcjonalność

Pobieramy repozytorium przez wtyczkę, wypakowujemy, przechodzimy do katalogu i możemy zobaczyć, że jest pusty. Po wpisaniu polecenia git status widać jednak jakie pliki są usunięte:

On branch master
Your branch is based on 'origin/master', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    .gitignore
        deleted:    .htaccess
        deleted:    .htpasswd
(...)

no changes added to commit (use "git add" and/or "git commit -a")

Git służy do przechowywania historii zmian. Poprzednie commity są w formacie binarnym, w najprostszy sposób możemy dotrzeć do nich używając polecenia git restore .

$ ls -a
.     .gitignore  admin     assets      cron         index.php   mediacacheAdv            modules     static
..    .htaccess   admin321  class       css          js          mediacacheArticle        resource    templates
.git  .htpasswd   ajax.php  config.php  imagick.php  mediaCache  mediacachePhotorelation  robots.txt  tmp

Jak widać powyżej, pliki się odtworzyły. Pomijając hasła wpisane na sztywno w skryptach. Możemy nawet udać na potrzeby edukacyjne, że ich nie było. Najbardziej zaciekawił mnie plik .htpasswd^[1]

Byłem ciekaw, czy uda mi się odgadnąć hasło do znalezionego użytkownika. Przykład jest zmyślony, ale ciąg zdarzeń analogiczny. Dla poniższego wpisu w .htpasswd:

admin:6YPqJe88Wz5fQ

Napisałem snippet w Pythonie i dopisałem kilka propozycji dla powyższego użytkownika, (chciałem chwilę później spróbować metodą słownikową) wyglądało to mniej więcej tak:

import crypt

passwords = ['admin', 'password', '123456', 'admin123']
hash = "6YPqJe88Wz5fQ"

for password in passwords:
    if crypt.crypt(password, hash) == hash:
        print(f"Password found: {password}")
        break
else:
    print("Password not found in common list")

Po uruchomieniu dostałem potwierdzenie:

$ python3 htpasswd.py 
Password found: admin123

Co stało się dalej?

Po moim zgłoszeniu część rzeczy została ukryta w taki sposób:

Tu się będę już czepiał, ale chcę pokazać dlaczego jawna wersja oprogramowania w komunikacie błędu daje atakującemu nadmierną ilość informacji. Powyższa wersja Apache2 wskazuje prawdopodobnie na Ubuntu 22.04 LTS (jammy). Dlaczego? Bo ostatnia najnowsza wersja z Ubuntu 20.04 LTS (focal) to 2.4.41^[2], natomiast w jammy już 2.4.52^[3]. Najnowszy commit również wskazywałby, że strona nie jest juz jakiś czas aktualizowana

Wnioski

Ogromna prośba, żeby nie trzymać w gicie jawnie haseł. To nie jest odpowiednie miejsce. Jak widać, nawet w przypadku korzystania z prywatnego repozytorium coś po drodze może pójść nie tak i hasła mogą wyciec.

https://pl.wikipedia.org/wiki/.htpasswd Dostęp 19.02.2026 ↩︎
https://launchpad.net/ubuntu/focal/+source/apache2 Dostęp 19.02.2026 ↩︎
https://packages.ubuntu.com/jammy/apache2 Dostęp 19.02.2026 ↩︎

Running Green Cell UPS app (GCUPS) on GNU/Linux server

Damian Fajfer — Sat, 16 Sep 2023 14:00:00 +0000

If you're one of these people you probably also want/need an UPS. Since I'm installing a data box I've been searching for an UPS to support the rest of my 11" rack and couldn't really find anything appealing to me on the local market from APC. After some research I realized that I would love to have an exchangeable battery so I've acquired a Green Cell UPS in the process. They advertised a dedicated software that comes with it but it didn't really matter to me until I've discovered that it supports several GNU/Linux distributions.



I like how Green Cell UPS looks similar to the EON from the video game Original War

GC UPS App

On their download page (edit: or my GitHub) they offer gcups (that's how it's called) for all modern desktop systems - Windows, MacOS and, surprisingly, Linux support for .deb, .rpm, .pacman and .tar.gz (with some shell scripts). There's a pretty solid multi-platform choice as they are using Electron running on Chromium. The worst thing is that this software isn't open source.

All in all, Linux support convinced me to give it a try. I'm not going to do much of a review of it. Once I ran some successful tests via webGUI I thought that it could be useful to run it, just not on my desktop. I've tried running gcups with some parameters to demonize it but to no avail. At the time of writing this article I'm using version 1.1.7 released 02.06.2023. Running gcups on my server gave me this output:

$ gcups 
[371031:0915/014627.729749:ERROR:ozone_platform_x11.cc(240)] Missing X server or $DISPLAY
[371031:0915/014627.729793:ERROR:env.cc(255)] The platform failed to initialize.  Exiting.
Segmentation fault (core dumped)



Support replying to me that there is no way to run gcups without the GUI, let's prove them wrong

Running gcups in CLI environment

Searching for some information on running gcups didn't get me anywhere (version 1.0.0 was published in June 2022) so I started tinkering a bit. Even if I went as far (or as near) as getting this running without X server I'd still need to enable HTTP server in the application settings. I've been doing the usual stuff but I didn't notice any new processes starting up if I enable the web server, strings didn't give me any insightful output non-specific to Chromium, I couldn't find anything in the ~/.config/gcups either. There is also an /opt/gcups directory being created during the install so I've eventually began searching in the db folder and - hooray - this was the place.

/opt/gcups/db$ ls
gcups-rxdb-0-                                                           gcups-rxdb-0-scheduler-mrview-c37be66b94b0bdae91ef3fcbeab58edf
gcups-rxdb-0-device_parameters                                          gcups-rxdb-0-settings-local
gcups-rxdb-0-device_parameters-local                                    gcups-rxdb-0-test
gcups-rxdb-0-device_parameters-mrview-99560a34de60f5074dcd2be42069d585  gcups-rxdb-0-test-local
gcups-rxdb-0-register                                                   gcups-rxdb-0-test-measurement
gcups-rxdb-0-register-local                                             gcups-rxdb-0-test-measurement-local
gcups-rxdb-0-register-mrview-692a6698c32319395128b449dfae271e           gcups-rxdb-0-test-measurement-mrview-99560a34de60f5074dcd2be42069d585
gcups-rxdb-0-_rxdb_internal                                             gcups-rxdb-0-test-mrview-8b2440dfbb354345cc5c69a011a2beb9
gcups-rxdb-0-scheduler                                                  gcups-rxdb-0-test-mrview-8b851648c605dcf349b861f65fdffef5
gcups-rxdb-0-scheduler-local                                            gcups-rxdb-1-settings  <--- this is the one that's interesting to us
gcups-rxdb-0-scheduler-mrview-2f6b156c4b77dd00407dbed941ee1abf          pouch__all_dbs__

I've accessed gcups-rxdb-1-settings database using LevelDB via python:

import plyvel
db = plyvel.DB('/opt/gcups/db/gcups-rxdb-1-settings')

for key, value in db:
    print(f"{key.decode()}: {value.decode()}")

Which gives us an interesting output:

ÿby-sequenceÿ0000000000000001: {"api":{"port":8080,"password":"password hash here","enable":true,"salt":"password salt here"},"_attachments":{},"_id":"a733f0a7-4fe2-4120-8603-775370fd871a","_rev":"12-c2e2e2d475614a9aed42806e63a38338"}

To break up the most interesting parts:

port is pretty obvious, this is just an HTTP port for our webserver
enable tells us if the HTTP server is enabled by default on gcups run

What I found is that you can actually just replace the first and only sequence for gcups to work. There's a (4th from the end) key called document-store which stores all revs of the previous sequences as well as the winningRev but only the seq value matters in this case, which is in most cases your last by-sequence.

Generating your own by-sequence

Now that we know how to access gcups settings without running the gcups itself we need to replace port (optionally), enabled, password and salt. I don't know how to generate salt and password by hand so I'd recommend installing gcups locally, configuring it and then exporting this setting to your server. Keep in mind, that you can't change your password from the webGUI. To do this simply install gcups locally, set the password up and enable HTTP server in the settings. Afterwards proceed to /opt/gcups/db/gcups-rxdb-1-settings and perform PUT on your data:

import plyvel
db = plyvel.DB('/opt/gcups/db/gcups-rxdb-1-settings')

db.put(b'\xc3\xbfby-sequence\xc3\xbf0000000000000001', b'{"api":{"port":8080,"password":"password hash here","enable":true,"salt":"password salt here"},"_attachments":{},"_id":"a733f0a7-4fe2-4120-8603-775370fd871a","_rev":"12-c2e2e2d475614a9aed42806e63a38338"}')

You don't need to do anything else now. I've mimicked xserver by using xvfb and it enables you to run gcups on your server this way:

xvfb-run gcups

Afterwards, you can access your gcups webGUI on the host:port on your server you specified in the by-sequence

Closing thoughts

I've contacted the support two times to confirm that the software is not supposed to work without GUI. There is going to be a purely cli solution for gcups and it's on the Green Cell's roadmap but it is unknown when it's going to be released which made me spend one evening trying to run it non-intended way.

I'm thinking about containerization of the complete solution sometime this year, I will update the blogpost afterwards and provide a ready docker-compose with USB passthrough to the container (UPS connects via USB to the machine for gcups to be functional). It would be cool if I also learned how to generate pass/salt combination for gcups as I haven't given it much thought.

And last but not least - there is no point for such software to NOT be free software. The only meaningful thing this would expose would be communication scheme between the software and the UPS. So what? Every UPS manufacturer communicates to his UPS in a different way as there is no general protocol on how it should be done. I don't think that it's much of a secret and that it eventually couldn't be exposed with some work anyway. Even if gcups would be free and people decided to use non-Green Cell developed solutions it would still be beneficial for Green Cell as, because of the different communication schemes, these 3rd party solutions would still only support their product.

Now that it's closed source my work was focused on bypassing xserver requirement instead of making their product better and their product wouldn't exist if not for open source anyway.

UPDATE 03.04.2024

Hey guys! Motivated by comments from Robert I managed to dockerize the above solution. There's still some work but I'm willing to take it on and maintain the project.

https://github.com/fajfer/gcups

docker pull ghcr.io/fajfer/gcups:1.1.7

UPDATE 19.08.2024

Due to popular demand I've created a Matrix chat room so I can aid you at a whim (or a bit later) - https://matrix.to/#/#gcups:fsfe.org

Cosign signatures lifecycle in Artifactory

Damian Fajfer — Sun, 23 Jul 2023 14:00:00 +0000

Additionally, we'll delve into a proposed solution for copying the signature to a target repository during artifact promotion or copying phases, addressing potential challenges in the process.

Details regarding signing and verifying docker containers won't be covered in this blog post. This has been very well explained in other people blog posts^[1], as well as in the official documentation^[2]^[3]. It's safe to say that it works since at least 2021.

Working with Artifactory

Before going on with signing we need to authenticate ourselves to the docker registry. I'm using Artifactory docker registry^[4] as an example in this scenario.

cosign login -u {{ username }} -p '{{ password }}' x.artifactory.com

Cosign could return an error if you provide an URL with the schema:

Error: registries must be valid RFC 3986 URI authorities: https://x.artifactory.com
main.go:74: error during command execution: registries must be valid RFC 3986 URI authorities: https://x.artifactory.com

As a solution simply omit the schema (https:// in the above example).

When cosign has successfully logged in, build and push the image as usual. Afterwards, you should sign your docker image using cosign sign. If you did everything right to this point, executing cosign verify as a sanity check on the same machine will provide the following output:

$ cosign verify --key cosign.pub x.artifactory.com/fajfer/image:example
The following checks were performed on these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"sha256:87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8"},"Type":"cosign container image signature"},"Optional":null}

You can repeat the command on a different machine to verify that the signature has been successfully uploaded. The output should remain the same and the signature should be visible in the webUI:

So what's the problem?

As per documentation:

Cosign documentation @ af555d5

Signatures are stored as separate objects in the OCI registry, with only a weak reference back to the object they "sign". This means this relationship is opaque to the registry, and signatures will not be deleted or garbage-collected when the image is deleted. Similarly, they can easily be copied from one environment to another, but this is not automatic.

If your artifact lifecycle ends here and images from here are being deployed to production or are available to public then that's it, you're done. Otherwise, if you want to promote your images or copy them somewhere else then you'll notice that while your artifacts are getting promoted to the target repository, their signatures are left intact in the source repository. Which means that if you build and sign artifacts in the repository x, then after promoting it to repository y cosign will give you this sad response:

$ cosign verify --key cosign.pub y.artifactory.com/fajfer/image:example
Error: no matching signatures:

main.go:52: error during command execution: no matching signatures:

What's wrong, right? It just worked perfectly in the old repository.

The proposed solution

We need to copy the signature to the target repository. After the Promote Docker Image REST API request we need to do a Copy Item request to copy the signature. There's an important detail here - cosign names the signature after SHA256 of manifest.json of our image. Luckily, we can easily access that information by executing File Info request. We can also calculate this ourselves but I assume you don't have the image locally anymore during the promotion/copy phase.

To understand the solution better and get an idea of how your requests should look like, here's an example in Ansible code that could be used to implement a solution in your CI system:

- name: Promote Docker Image
  # https://jfrog.com/help/r/jfrog-rest-apis/promote-docker-image
  uri:
    url: "{{ artifactory_url }}/api/docker/{{ source_repo }}/v2/promote"
    method: POST
    url_username: "{{ username }}"
    url_password: "{{ password }}"
    force_basic_auth: true
    body_format: json
    body:
      targetRepo: "{{ target_repo }}"
      dockerRepository: "{{ docker_repository }}"
      copy: true

- name: Get manifest.json (File Info)
  # https://jfrog.com/help/r/jfrog-rest-apis/file-info
  uri:
    url: "{{ artifactory_url }}/api/storage/{{ source_repo }}/\
      {{ file_path }}/{{ tag }}/manifest.json"
    method: GET
    url_username: "{{ username }}"
    url_password: "{{ password }}"
    force_basic_auth: true
  register: manifest

- name: Copy cosign signature (Copy Item)
  # https://jfrog.com/help/r/jfrog-rest-apis/copy-item
  uri:
    url: "{{ artifactory_url }}/api/copy/{{ source_repo }}/\
      {{ source_file_path }}/sha256-{{ manifest.json.checksums.sha256 }}.sig\
      ?to=/{{ target_repo }}/{{ target_file_path }}"
    method: POST
    url_username: "{{ username }}"
    url_password: "{{ password }}"
    force_basic_auth: true

This approach makes the best use of Artifactory's API and doesn't require the image and signature to be downloaded locally at all.

Closing thoughts

Cosign support of Artifactory is very well done and the Artifactory knows that it serves you signed images as it sends you a signature along with the container after executing docker pull. The API doesn't reflect that though, but that's hopefully going to change in the future. Container signing becomes more popular and more accessible thanks to tools like cosign, notary and kyverno to name a few so doing workarounds like this shouldn't be required in the future.

Jabar Asadi, "Digital Signature With Cosign" May 4, 2023. https://eng.d2iq.com/blog/digital-signature-with-cosign/ Accessed 22.07.2023 ↩︎
Sigstore, "Signing Containers" https://docs.sigstore.dev/cosign/signing_with_containers/ GitHub: 18b11e2 ↩︎
Sigstore, "Verifying" https://docs.sigstore.dev/cosign/verify GitHub: 4186c93 ↩︎
JFrog Artifactory Documentation, "Docker Registry" https://jfrog.com/help/r/jfrog-artifactory-documentation/docker-registry Accessed: 23.07.2023 ↩︎