Software-update: GitLab 8.16.1 / 8.15.5 / 8.14.7 / 8.13.12

GitLab kun je vergelijken met het bekendere GitHub, maar bevat een aantal subtiele verschillen. Het is een omgeving voor het beheren van Git-repositories on-premises en wordt uitgegeven onder de MIT Expat-licentie en ontwikkeld in Ruby on Rails. Het is beschikbaar in twee versies, namelijk de gratis te gebruiken Community Edition en een betaalde Enterprise Edition met meer functies die op grote bedrijven zijn gericht. De twee smaken worden op deze pagina uiteengezet. Het ontwikkelteam heeft updates voor GitLab versies 8.16, 8.15, 8.14 en 8.13 uitgebracht, om enkele beveiligingsproblemen te verhelpen.

GitLab 8.16.1, 8.15.5, 8.14.7, and 8.13.12 Security Release
Today we are releasing versions 8.16.1, 8.15.5, 8.14.7, and 8.13.12 for GitLab Community Edition (CE) and Enterprise Edition (EE). These versions contain important security fixes, and we recommend that all affected GitLab installations be upgraded to one of these versions.

Prevent users from creating notes on resources they can't access
An attacker was able to use the API to post comments on resources that they would not otherwise be able to view, which would "subscribe" them to the notifications for that resource and allow them to receive future updates about it, which may contain sensitive information. See #26249 and #26250 for more details.

Prevent users from deleting system deploy keys via the project deploy key API
An attacker was able to delete a system-level deploy key by deleting it from a project they owned via the Deploy Key API. See #26243 for more details.

Ensure export files are removed after a namespace is deleted
If a user performed a project export and then deleted (or moved) its containing namespace, an attacker could claim the namespace and access the existing project export if less than an hour had passed. We now ensure that project exports are immediately removed along with the namespace. See #26242 for more details.

Versienummer	8.16.1 / 8.15.5 / 8.14.7 / 8.1
Releasestatus	Final
Besturingssystemen	Linux
Website	Fabrikant
Download	https://about.gitlab.com/downloads
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (8)

Gitlab's maandelijkse release cycle werkt eigenlijk niet zo goed voor hen. Elke keer moeten ze na een paar dagen al een .1 releasen met daarin best ernstige fixes. Dit is al meerdere jaren hetzelfde liedje - ze lijken er niet echt van te leren.

Release early, release often is leuk maar alleen als je geautomatiseerd kunt testen. Dat lijkt niet het geval.

Ze testen geautomatiseerd, maar ze gaan er ten onrechte vanuit dat dat alles vangt. Tests kunnen alleen bugs vinden waarvan je verwacht dat ze er zijn. Het kan helpen om code kwaliteit te vergroten, maar het is geen alternatief voor code reviews of design guidelines.

Gitlab hanteert het "Move fast and break things" principe. Dat is heel hip. Echter, plekken waar security en data-veiligheid relevant zijn (oftwel: bijna overal), hebben liever iets meer zekerheid dan nieuwe half-af features.

Als ze na een paar dagen al een .1 uit moeten brengen dan testen ze niet de juiste zaken lijkt me. Zo snel een fix aanbrengen doe je voor showstoppers (kan niet bij mijn data, alle pagina's zijn in het chinees). Automated scenario testing (doe een commit, haal deze op, doe een branch, doe een merge etc.) halen dat soort bugs er wel uit. Ik ken de gitlab testcycle niet, maar als een gebruiker meld dat er steeds een .1 volgt na een paar dagen dan heb ik wel een bruin vermoeden waar het schort.

Als je Gitlab zelf host (waarom zou je anders geïnteresseerd zijn in deze releases?), kun je er ook van leren: laat anderen de kolen uit het vuur halen met de .0 releases en wacht zelf een paar dagen op de .1/.2/.x.

Blijkbaar kunnen ze heel makkelijk een release klaarmaken, gezien het grote aantal releases wat ze doen (zo is er ook 8.15.5; dat is dus al 6 releases in iets meer dan een maand tijd voor 8.15.x).

Aangezien security fixes als deze ook altijd naar oudere major versies gebackport worden, kun je rustig op een iets oudere major versie blijven hangen tot de ergste bugs eruit zijn. Het vereist hooguit een beetje extra geduld omdat je niet gelijk de nieuwste features hebt, maar dat vind ik zelf een kleine moeite.

Als je Gitlab zelf host (waarom zou je anders geïnteresseerd zijn in deze releases?)

Ik host inderdaad zelf, aangezien Gitlab deze lekke versies ook klakkeloos uitrolt op haar eigen platform. Ik wil mijn spulletjes daar zeker niet hebben.

laat anderen de kolen uit het vuur halen met de .0 releases en wacht zelf een paar dagen op de .1/.2/.x.

Dat is precies wat ik doe, maar dat is nog steeds een loterij. De .1 wordt al snel gevolgd door een .2 en een .3. Welk moment je ook kiest, je heb geen garantie dat de kwaliteit acceptabel is. Bugfixes worden niet gegarandeerd gebackport naar eerdere versies, dus je moet per se de laatste release gebruiken, zelfs al is die dus regelmatig gaar.

Ik zou echt heel graag een 6-maanden LTS versie van gitlab hebben, waar alle security- en dataloss fixes naar gebackport worden, maar verder niets.

En inmiddels is 8.16.2 / 8.14.8 ook al weer uit, het is te veel om bij te houden in de meuktracker .

https://about.gitlab.com/...-8-dot-16-dot-2-released/

[Reactie gewijzigd door Jeroen Sack op 26 januari 2017 09:55]

Wij hosten onze Gitlab EE instantie hier op het werk op een intern netwerk (toegankelijk met VPN van buiten) en zijn er, ondanks de enkele bug nu en dan, behoorlijk tevreden over. Vooral ook de CI-functionaliteit scoort punten!