Privacy Policy

This policy explains how personal data is processed when you use the Git hosting service at git-staging.halogenos.org. It is provided pursuant to Articles 13 and 14 GDPR.

Diese Seite auf Deutsch

Controller

Simão Gomes Viana
c/o IP-Management #10911
Ludwig-Erhard-Str. 18
20459 Hamburg
Germany

Data protection enquiries: privacy@halogenos.org

A data protection officer has not been appointed, as the statutory thresholds of § 38 BDSG are not met.

What we process, why, and on what basis

Account data

Accounts on this service are not created here. Authentication is delegated to the halogenOS single sign-on at sso.halogenos.org, operated by the same controller under its own privacy policy. When you sign in for the first time, an account is created from the data that sign-on transmits: your username, your email address, your display name, and — where set — your avatar and role assignments.

Purpose: providing you with an account and access to the service.
Legal basis: Article 6(1)(b) GDPR (performance of a contract or steps prior to it).

Repository content

Anything you push, upload or enter — repository contents, commits, branches, tags, comments and the metadata that accompanies them — is stored so the service can perform its function. Repositories on this instance are public and readable by anyone, without an account.

Note that Git commits permanently embed the author name and email address that you configured in your Git client. This data becomes part of the repository history, is copied by everyone who clones it, and cannot be altered afterwards without rewriting that history. Choose those values deliberately; git config user.email accepts any address you are willing to publish.

Purpose: providing the hosting service.
Legal basis: Article 6(1)(b) GDPR.

Personal data inside repositories we republish

Repositories here include forks and mirrors of other open-source projects. Their history carries commit metadata — names and email addresses — belonging to contributors who have never had any relationship with this service. That is personal data obtained from somewhere other than the data subject, which makes this service a controller for it and brings Article 14 GDPR into play.

Categories of data: author and committer name, email address, and where present the username — exactly as each contributor recorded them in their own commits.
Source: the public upstream repositories the fork or mirror was taken from.
Recipients: anyone who views, clones or mirrors the repository. Authorship records travel with the code because they are what the licence requires in order to redistribute it lawfully: a recipient needs them in order to comply with its attribution terms.
Retention: for as long as the repository remains published. Commit history is immutable by design and is not pruned.
Purpose: distributing derived open-source software with its history and attribution intact. Git identifies every commit by a hash computed over that metadata, so it cannot be stripped without rewriting the history and invalidating every existing clone, and the licences these projects use generally require attribution to be preserved.
Legal basis: Article 6(1)(f) GDPR. In the balancing exercise: the contributors published this data themselves, in a public repository, under a licence that expressly anticipates redistribution; it is limited to what they chose to place in their own commits; and preserving it is what both the licence and the tooling require.

Article 14(1) would ordinarily require each of those contributors to be notified individually. For repositories with thousands of contributors that is a disproportionate effort within the meaning of Article 14(5)(b), which is why this notice is published instead — that is precisely the alternative the provision prescribes.

If you are one of those contributors and wish to exercise your rights under Articles 15 to 21, write to privacy@halogenos.org. Every request is answered by a person; no decision here is automated.

We would rather state the limit plainly than imply more than we can deliver. A repository can be removed from this service, and we will do that where the balance favours it. What we cannot do is alter or delete data inside an existing development history: Git identifies every commit by a hash computed over the author and committer fields, so changing them rewrites every subsequent commit, invalidates every signature and breaks every clone, tag and reference derived from them. Nor would it achieve much — the same commits exist in the upstream project and in every other copy that has ever been cloned, and none of those are within this service’s control. This is a property of the version control system itself rather than a policy choice, and the same limit applies to every Git host and archive.

SSH keys and access tokens

Public SSH keys and API access tokens you register are stored so that Git operations and API requests can be authenticated to your account.

Neither is required in order to use the service — the web interface works without them — and deleting a key or token ends this processing immediately.

Purpose: providing the optional access method you chose to enable.
Legal basis: Article 6(1)(b) GDPR, assessed for this feature on its own: storing the key is necessary to provide the SSH or API access you asked for by adding it, rather than necessary for the service as a whole.

Server logs

The web server and the application record technical data about requests: IP address, timestamp, requested path, HTTP status, referrer and user agent. These logs are used to operate the service, to diagnose faults, and to detect and defend against attacks and abuse. They are held on the server, rotated automatically, and are not used to profile users or combined with account data for any other purpose.

Purpose: operation, security and troubleshooting.
Legal basis: Article 6(1)(f) GDPR (legitimate interest in a functioning, secure service).

Cookies

This service sets only cookies that are strictly necessary for it to work: a session cookie that keeps you signed in, a CSRF token that protects forms against cross-site request forgery, and a cookie recording your interface language. No analytics, advertising, tracking or profiling cookies are set, and no consent banner is required because § 25(2) TDDDG exempts strictly necessary storage.

Legal basis: § 25(2) TDDDG in conjunction with Article 6(1)(b)/(f) GDPR.

What we do not do

No advertising is displayed. No web analytics, tracking pixels, social media widgets, fonts or scripts are loaded from third parties — every asset is served from this domain. No personal data is sold, rented or transferred for marketing purposes. No automated decision-making or profiling within the meaning of Article 22 GDPR takes place. Notification emails are not sent by this service.

Recipients and processors

No data is transferred to a third country outside the EU/EEA. The servers and all stored data are located in the European Union.

Retention

Repository content and account data are retained until you delete them or ask for the account to be deleted. Server logs are retained only as long as needed for operation and security and are rotated automatically. Data that must be kept under statutory retention obligations is retained accordingly and otherwise restricted from processing.

Your rights

Under the GDPR you have the right to obtain confirmation as to whether your data is processed and to access it (Article 15), to rectification (Article 16), to erasure (Article 17), to restriction of processing (Article 18), to data portability (Article 20), and to object to processing based on legitimate interests (Article 21). Where processing rests on consent, you may withdraw it at any time with effect for the future.

To exercise any of these, write to privacy@halogenos.org.

One practical limit deserves stating plainly: content you have published into a public Git repository — including author names and email addresses inside commits — may already have been cloned by others. Deleting it here cannot reach those copies, and rewriting published history is not always possible.

Right to lodge a complaint

You may lodge a complaint with a supervisory authority, in particular in the Member State of your habitual residence, place of work, or the place of the alleged infringement. The authority competent for this controller is:

Bayerisches Landesamt für Datenschutzaufsicht (BayLDA)
Promenade 18, 91522 Ansbach
https://www.lda.bayern.de

Changes

This policy may be updated as the service changes. The current version is always available at this address.

Last updated: 26 July 2026