Atlassian waarschuwt voor ernstige Jira-kwetsbaarheid

Atlassian meldt enterpriseklanten dat er een ernstige kwetsbaarheid in Jira Data Center en Jira Service Management Data Center gedicht is. De kwetsbaarheid maakte dat aanvallers code konden uitvoeren.

Atlassian waarschuwde klanten afgelopen week dat de kwetsbaarheid in Jira Data Center en Jira Service Management Data Center automatisch ook Jira Software Data Center en Jira Core Data Center treft. Het bedrijf adviseert klanten zo snel mogelijk te upgraden naar versies die een fix hebben gehad. Atlassian zet op zijn site op een rij welke versies getroffen zijn en welke een patch hebben ontvangen.

De kwetsbaarheid betreft CVE-2020-36239 en maakt dat aanvallers die hiervoor geen autorisatie hebben, op afstand code kunnen uitvoeren. De bron van de oorzaak ligt bij het ontbreken van authenticatie bij Ehcache RMI. Aanvallers konden via poort 40001 en mogelijk 40011 via deze netwerkdienst verbinding maken. Atlassian adviseert als workaround dat gebruikers de toegang tot Ehcache RMI-poorten via de firewall beperken tot uitsluitend Jira Data Center, Jira Core Data Center, Jira Software Data Center en Jira Service Management Data Center en tot alleen cluster instances.

Jira wordt volgens Atlassian door meer dan 180.000 klanten gebruikt voor bugtracking en projectmanagement, maar niet duidelijk is hoeveel klanten er zijn voor Jira Data Center en Jira Service Management Data Center.

Reacties (77)

[roland83]

Als je Jira van buitenaf wilt kunnen benaderen, dan is het wel slim om de Jira-server rechtstreeks aan het internet te hangen. Dat is met geen enkele server slim. Dus iedereen die Jira host achter een firewall en reverse proxy heeft geen last van deze kwetsbaarheid, de poorten die nu kwetsbaar zijn, zijn niet te zien van buitenaf.

[kodak]

Door je software achter een firewall te zetten heb je hooguit minder onbekenden die er gebruik van kunnen maken. Maar dat gebruikers van een netwerk normaal toch eerst op deze software moeten inloggen is er natuurlijk ook niet voor niets. Ook die gebruikers krijgen niet zomaar alle rechten en zijn maar beperkt te vertrouwen. Zeker als die gebruikers op dat netwerk zelf applicaties of (malware) kunnen downloaden en uitvoeren en er ook weinig andere bescherming is ben je dan dus niet zomaar beter af.
Het lijkt toch wer beter om eens af te vragen waarom je als bedrijf deze software hebt gekozen terwijl er dit soort ernstige lekken in blijken te zitten. Waarom vertrouw je als bedrijf de verkoper van deze software? Het antwoord kan niet zijn omdat ze vast wel updates uitbrengen als het misschien al te laat is.

[Verwijderd]

Waarom vertrouw je als bedrijf de verkoper van deze software?

volgens die logica kun je niets meer vertrouwen. (wat op zich een kern van waarheid heeft, maar je doet nu net alsof er iets mis is specifiek met atlassian. beetje captain hindsight gehalte )

[kodak]

Opmerken wat al veel langer bekend is (je kan software niet zomaar vertrouwen) heeft hier betrekking op Atlassian vanwege de discussie over dit nieuws. Maar dat wil uiteraard niet zeggen dat het alleen daarop betrekking heeft, laat staan dat je het maar moet (blijven) accepteren terwijl er in 2021 nog steeds dit soort blunders van fouten in software worden gemaakt. Dan is het toch echt tijd om bij keuze van software veel strenger te zijn om de ontwikkelaars en verkopers te laten bewijzen hoe ze deze fouten werkelijk proberen te voorkomen, in plaats van te willen geloven in beweringen en gebrek aan verantwoording.

[Verwijderd]

ik denk dat complexe software altijd tegen dit soort fouten op blijft lopen, zelfs al zou je elk bedrijf dat in de fout gaat boycotten. complexiteit maakt dingen gewoon moeilijk

[kodak]

Is dat een redelijk excuus om dan maar niet van Atlasian of andere software leveranciers te eisen dat ze transparant zijn hoe ze op zijn minst bewijzen dit soort enorm onveilige lekken te voorkomen? Lijkt me eerder dat het juist nodig is om als klant eisen te stellen al je er samen met miljoenen anderen risico door loopt.

[PageFault]

Vrij recent had Kaseya dat ook, iets langer geleden hadden TeamViewer en Citrix wat lekken, Zo kun je geen enkel bedrijf vertrouwen

[Recklezz]

Het schijnt zelfs dat er soms in Microsoft OS producten ook een foutje blijkt te zitten.

[PageFault]

Dat is helaas niet waar, er zit regelmatig een foutje in, zoals het verkrijgen van admin rechten door het registry en ook vrij recent het hele spooler debacle ("PrintNightmare")

[Recklezz]

Dat is ook wat ik met een licht gevoel voor sarcasme probeerde te zeggen...

[PageFault]

Maar als echte zolderkamer authist herken ik die fijne nuance niet, zeker niet via een forumachtig iets ipv face 2 face

[01001000]

Het lijkt toch wer beter om eens af te vragen waarom je als bedrijf deze software hebt gekozen terwijl er dit soort ernstige lekken in blijken te zitten. Waarom vertrouw je als bedrijf de verkoper van deze software? Het antwoord kan niet zijn omdat ze vast wel updates uitbrengen als het misschien al te laat is.

Ze hebben niet bepaald een reputatie van veel grote lekken, ze hebben wel een reputatie van effectieve software en goede aanpasbaarheid, goede plug-ins en een prima breed pakket (met Confluence er bij bijvoorbeeld).
Als je elke software waar een grote bug in word gevonden niet meer gebruikt dan kom je toch wel erg snel uit op het enige veilige rekentuig, een abacus. Tenzij je een werknemer bent van een ander bug/issue tracking systeem snap ik je reactie ook niet eerlijkgezegd

[kodak]

Het lijkt me niet redelijk om af te wachten of anderen ooit lekken vinden, om vervolgens het te bagatelliseren omdat er weinig ernstige lekken zijn gevonden. Je hebt geen veilige software door er blind op te vertrouwen dat anderen daar wel voor zorgen en al helemaal niet om vervolgens bewijs voor risico daarva alsnog nauwelijks te willen accepteren. Dan ben je meer bezig problemen mogelijk te maken en laten bestaan dan verantwoordelijkheid te nemen veilige software te willen gebruiken.

[jimshatt]

Ik snap werkelijk geen woord van je verhaal. Het lijkt wel spam maar ik mis de dubieuze link.

[sfranken]

Door je software achter een firewall te zetten heb je hooguit minder onbekenden die er gebruik van kunnen maken. Maar dat gebruikers van een netwerk normaal toch eerst op deze software moeten inloggen is er natuurlijk ook niet voor niets. Ook die gebruikers krijgen niet zomaar alle rechten en zijn maar beperkt te vertrouwen.

Door Jira spullen achter een firewall te draaien beperk je niet alle vectoren. Interne gebruikers kunnen ook rotzooi downloaden of dingen proberen die ze niet mogen.

Het lijkt toch wer beter om eens af te vragen waarom je als bedrijf deze software hebt gekozen terwijl er dit soort ernstige lekken in blijken te zitten. Waarom vertrouw je als bedrijf de verkoper van deze software? Het antwoord kan niet zijn omdat ze vast wel updates uitbrengen als het misschien al te laat is.

Waarom wordt Atlassian blind vertrouwd? (Is mijn gok, hier heb ik ook moeite mee een punt te vinden)

Dit is mijn interpretatie, in ieder geval.

[kodak]

Kan je dan uitleggen wat je er niet van snapt of waarom je het zelfs spam wil noemen? De discussie is dat jira grote lekken blijkt te hebben en dat een firewall niet zomaar een oplossing is tegen die problemen.

[mosm]

-

[Reactie gewijzigd door mosm op 25 juli 2024 04:23]

[Niemand_Anders]

Je kunt ook een VPN server gebruiken. Geen VPN policy bestand, geen verbinding met het netwerk waarop Jira (en mogelijk git, nextcloud, bitwarden en andere dev services draaien).

Je primaire beveiliging is dan de (IPSEC) VPN verbinding. Omdat alles achter een VPN hangt, is het veel lastiger om deze services aan te vallen als er een kwetsbaarheid bekend wordt..

Alles wat je niet publiek wilt delen, maar wel beschikbaar moet zijn voor medewerkers kun je het beste achter een VPN gooien. Als je met policy certificaten werkt en iemand vergeet de laptop in het openbaar vervoer, dan kun je simpel dat certificaat intrekken en vervolgens kunnen zij niet meer van de VPN gebruik maken. Je bent in principe alleen kwetsbaar tussen het moment dat je de laptop verliest (of gestolen wordt) en het moment dat de systeem beheerder het certificaat intrekt en er vanuit gaande dat je eigen medewerkers niet zelf de boel gaan proberen te hacken..

[kodak]

Je kan natuurlijk een vpn gebruiken waardoor een beperkt aantal mensen bij de software kan komen. Het zijn alleen zeer ernstige kwetsbaarheden omdat het veel rechten geeft, niet omdat maar een beperkt aatal mensen gebruik van kunnen maken. Een vpn beperkt slechts het aantal mensen, het zorgt er nog steeds niet voor dat daar geen criminelen tussen zitten. Het is dus nog steeds belangrijk niet zomaar op software en beveiligingsoplossingen te vertrouwen.

[Blockchain]

Uiteindelijk zul je toch altijd iets aan het internet moeten hangen als je wilt dat je software remote beschikbaar wordt. Of dat nou een jumphost, een VPN server of de applicatie direct is. En uiteindelijk zul je toch iets van software moeten gaan vertrouwen. Zelfs al gebruik je uitsluitend open-source software, je kunt nooit alle broncode controleren en zelf compileren.

Daarom is het goed om te werken met meerdere vectoren van beveiliging. Je vertrouwt de applicatie, maar als deze niet publiek hoeft te zijn dan gebruik je ook een VPN bijvoorbeeld. En daarnaast maak je ook back-ups voor als er toch iets mis gaat. Eventueel kun je gegevens en rollen verdelen over meerdere applicaties, zodat als er toch iets gelekt wordt dat het lek tenminste is gekaderd. En ten slotte doe je aan regelmatige updates, monitoring en auditing van je omgeving waarbij je onder andere controleert op frauduleuze activiteit.

[kodak]

Wij zijn het denk ik behoorlijk met elkaar eens. Maar waar de discussie mee begon, dat tweakers beweren dat een firewall het probleem verhelpt, of een vpn, is heel zorgelijk. Zeker als tweakers dan ook nog geen interesse hebben in een discussie waarom dat niet klopt en wat meer kan helpen. Dan lijkt er meer op dat het niet gaat om beveiliging maar om maar iets beweren en doen omdat het kan.

[roland83]

Ik heb in mijn reactie niet genoemd dat een firewall het probleem verhelpt. Ik denk ook niet dat dat zo is, en denk ook niet dat dat hier door iedereen gezegd is. Het enige wat ik in mijn bericht bedoel is dat je met een firewall en reverse proxy alleen de publieke poort van Jira beschikbaar maakt, dat is dus poort 80. Dat er op dezelfde Jira-server meer poorten open staan, en dat daar kwetsbaarheden in zitten vind ik ook een kwalijke zaak. Met een firewall en proxy houd je publieke toegang tot die poorten tegen. Niet meer en niet minder. Het neemt het probleem niet weg, je hebt het enkel omzeild.

[kodak]

Dus iedereen die Jira host achter een firewall en reverse proxy heeft geen last van deze kwetsbaarheid

[roland83]

Als je regelt dat poorten 40001 en 40011 van buitenaf niet kunt bereiken in die firewall, dan ja. In het CVE-artikel staan alleen deze poorten vermeld.

[kodak]

Het gaat er niet om welke poort er staat maar wie je met een firewall niet tegen gaat houden. Net doen alsof er in een bedrijf waarbij mensen moeten inloggen op jira geen risico is is niet realistisch. Anders kan je net zo goed die accounts en verschil in rechten gaan afschaffen. Een firewall vermindert dus hooguit de last.

[roland83]

Ik begrijp je punt denk ik niet helemaal. In het cve-artikel staan voor specifiek deze kwetsbaarheid alleen poorten 40001 en 40011 genoemd. Met een firewall en reverse proxy die deze poorten niet vanaf het internet bereikbaar maken, zorg je ervoor dat je vanaf het internet geen last hebt van deze kwetsbaarheid, de kwetsbare poorten zijn immers niet te bereiken.

Vanaf het interne netwerk natuurlijk wel. Voor zover dat te bereiken is vanaf je werkplek, want als je slim bent zet je ook dat gewoon dicht.

Accounts op Jira, rechten in jira, en dergelijke, staan volledig los van dit verhaal. Die hebben allemaal hun eigen risico's,die je met een firewall niet tegenhoudt.

[kodak]

Je stelt nu wat anders dan je eerst schreef. Waar een firewall volgens jou eerst zou zorgen dat je geen last van de kwetsbaarheid hebt maak je er nu van dat je met een firewall een beetje last kan wegnemen als een crimineel van het internet komt. Je lijkt dat punt dus te begrijpen.

Wat je nog niet duidelijk maakt is dat je de kwetsbaarheden ook begrijpt. De kwetsbaarheid is niet dat die poorten alleen voor gebruikers die er bij moeten beschikbaar zijn, maar dat die gebruikers die er bij kunnen de kwetsbaarheden alsnog kunnen gebruiken. Dat er geen authenticatie op die poorten is wil niet zeggen dat die ernstige kwetsbaarheden dus geen probleem zijn als gebruikers die kwetsbaarheden gebruiken.

Vergelijk het met toegang tot een laboratorium: dat alleen medewerkers van dat laboratorium daar toegang toe hebben wil niet zeggen dat je bescherming hebt dat ze procedures goed volgen of niet per ongeluk of opzettelijk resultaten wijzigen of vernietigen.

[roland83]

Ik snap wat je bedoelt. In de praktijk richt je het echter zo in dat iedereen alleen toegang heeft via de firewall die we allebei bedoelen. Alleen de systeembeheerder die de server beheert kan rechtstreeks via ssh inloggen op de Jira-server, verder niemand. In principe kunnen gewone gebruikers en ook ccriminelen dan niet bij de kwetsbare poorten.

Ik zie nu dat ik schreef: "Als je Jira van buitenaf wilt kunnen benaderen, dan is het wel slim om de Jira-server rechtstreeks aan het internet te hangen.". Ik bedoelde daar te schrijven dat het niet slim is. Maar dat staat er inderdaad niet.

[Reactie gewijzigd door roland83 op 25 juli 2024 04:23]

[kodak]

In de praktijk richt je het echter zo in dat iedereen alleen toegang heeft via de firewall die we allebei bedoelen. Alleen de systeembeheerder die de server beheert kan rechtstreeks via ssh inloggen op de Jira-server.

Dat is om twee redenen niet voldoende:
Ten eerste is het niet voor niets dat Atlassian hier duidelijk maakt dat er meerdere ernstige kwetsbaarheden zijn. Die zijn niet alleen ernstig omdat iedereen er bij zou kunnen: zoals je namelijk al stelt hoor je dat als bedrijf al goed gescheiden te houden. Ook voor wie dat al doet is het ernstig.
Die ernst komt doordat er niet zomaar een soort beheerder is die je overal maar bij laat. Ik geeft niet voor niets het voorbeeld van dat laboratorium waarbij procedures met deze kwetsbaarheden kunnen vermijden of ongelukken kunnen veroorzaken gevolgen kunnen zijn door alleen op beperkte toegang te vertrouwen.

[HeyImAllan]

Als je dit on premise hebt draaien is het risico al wat beperkt. Ehcache wordt alleen gebruikt voor inter node communicatie dus als reguliere user heb je daar niks te zoeken en kan dus prima afgeschermd worden door de firewall van het OS in te stellen. Sowieso heb ik nog geen Jira installatie gezien zonder reverse caching proxy ervoor, dat scheelt behoorlijk in de performance.

[djwice]

LOL ik heb maanden terug kwetsbaarheden gemeld, maar omdat ik dat niet via het bounty programma deed, maar direct bij de security officer en de eigenaar, nam de helpdesk het niet serieus. Ondanks dat beide hoge functionarissen aangaven per mail aan hun medewerkers dat dit urgent moest worden opgelost, verzandde het proces bij de helpdesk in onbegrip omdat ik er geen geld uit wilde slaan en daarom ongeloof of het wel echt was. Ondanks alle informatie aangedragen te hebben hoe te reproduceren, hebben ze gewoon nooit zelf de moeite genomen dat ook echt te doen. En is het nu nog niet opgelost.

Dus het interne proces zorgt er voor dat bekende kwetsbaarheden niet worden opgelost, ondanks dat de focus er van bovenaf wel op ligt.

[koentjuh1987]

wij gebruiken zelf trello. voor hetgeen we het nodig hebben werkt dat prima...

[n9iels]

nieuws: Atlassian neemt projecten-app Trello over voor 400 miljoen euro

[Bulkzooi]

Een product van Joel Spolsky? Dan moet het wel goed zijn. Ik vraag me af waarom die Trello verkocht heeft.

Is nou al de zoveelste keer dat een van mijn repositories een nieuwe eigenaar krijgt, met alle wijzegingen die daar mee gepaard gaan.

[jaspermeul]

En heb je er iets van gemerkt in de afgelopen vier jaar?
De overname was namelijk al in 2017

[Vihaio]

Het lijkt me sterk dat iemand dat heeft kunnen missen, je moet nu namelijk inloggen via Atlassian.
Daarnaast zijn de API-docs nu ook in de standaard Atlassian style, wat imo een grote achteruitgang is. Maar dat zal niet iedereen gemerkt hebben.

[koentjuh1987]

Dat wist ik al. Maar vind trello prima werken waarvoor wij het gebruiken.

[TheArtist]

Werk voor een kleinere organisatie en wij draaien Redmine (GplV2). Mist natuurlijk in de basis wel wat features en ziet er minder gelikt uit maar werkt heel vlotjes, heeft een REST API, en er zijn veel plugins voor en eventueel zelf makkelijk naar wens in te richten.

Heb zelf ook jaren met Jira gewerkt, als je het alleen als issue tracker gebruikt is het een dure oplossing.

[latka]

Duur? Je had de tot tien gebruikers versie voor 10 dollar eenmalig. Menig bedrijf die met Excel zat te issue tracken overgezet naar Jira voor dat geld.

[thePiett]

Ik vind het niet lekker gaan bij Atlassian. Jira en Bitbucket zijn enorm langzaam en er zijn regelmatig storingen. Daarnaast vind ik dat Bitbucket toch wat achterblijft bij Github, maar dat is een persoonlijk ding

Edit: SaaS

[Reactie gewijzigd door thePiett op 25 juli 2024 04:23]

[Pikkemans]

Zoals hierboven ook aangegeven. Self hosted is prima te doen. Gewoon een lading cpu en ram meegeven en het draait als een zonnetje.

[WarriorXK]

Helaas komt dat wel tot een einde, ze zijn gestopt met het verkopen van de on-premise versie, enkel nog de "Datacenter" versie waar je minimaal 42,000 USD per jaar voor moet betalen...

[Frame164]

Je kunt het altijd nog gewoon proberen/vragen om het onprem te kunnen krijgen. Bij mij op het werk hebben het net weer kunnen verlengen voor een paar jaar. Maar ik kan me voorstellen dat als je maar genoeg gebruikers hebt er altijd mogelijkheden zijn die doorsnee klanten niet hebben.

[WarriorXK]

Wij hebben aan het begin van dit jaar direct een verlenging gekocht voor 3 jaar, dus voorlopig zitten we nog wel even goed. Toch zijn we wel bezig met het kijken naar een alternatief.

[GeroldM]

De baas hier wil absoluut geen SaaS diensten voor alles wat hij als essentieel beschouwd. Aangezien Jira hier on-prem heel soepel loopt, vind hij de issue tracker dus essentieel. En hij is zeer zeker niet te spreken over de nieuwe richting die Atlassian inslaat.

Als je niet van heel veel van de Jira functionaliteiten gebruik maakt, dan is Fossil misschien een alternatief. Beschikbaar voor Windows, Linux, MacOS en Raspberry Pi. Nog geen 3 MByte om te downloaden.

Het is een decentraal versie controle systeem. Het lijkt sterk op Git, heeft ook een webserver waar je ook issues mee kan tracken, uren-registratie in kan bijhouden, er zit zelfs een Wiki in, alsmede een forum. En dat allemaal in een single executable (dus portable) welke gratis te gebruiken is in persoonlijke als commerciele omgevingen.

De standaard webinterface ziet er uit als een oude jaren '90 website. Maar je kan er themes voor downloaden. Er zit er eentje bij waardoor de web-interface ineens sterk lijkt op die van GitHub. Ook gratis.

Is van de maker van SQLlite, en deze persoon gebruikt Fossil al voor het SQLlite project sinds 2009, dus behoorlijk stabiel.

Als Fossil niet voldoet, misschien is dan dit GitHub project iets voor je: Jira_Clone. Is gebaseerd op React en Node.js.

** edit: aanpassing Rust naar React in laatste paragraaf
*** edit 2: Link naar Fossil toegevoegd

[Reactie gewijzigd door GeroldM op 25 juli 2024 04:23]

[WarriorXK]

Ik het persoonlijk ook veel waarde aan mijn stack op eigen hardware hosten. Al is het maar omdat wij vaak met medische data werken en ik dat liever zelf in handen heb.

Wij zijn op dit moment in gesprek met gitlab, zij gaven aan bezig te zijn met een grote uitbouw op hun ticketing systeem als response op de "Jira word cloud only" actie van Atlassian. En zeker aangezien wij al Gitlab gebruiken kan dit een interessant alternatief zijn.

Dat Jira_clone project ziet er wel erg interessant uit, heeft alleen wel aardig wat werk nodig voordat wij het zouden kunnen inzetten helaas. Al is het alleen al om het feit dat er (aldus de Readme) geen authenticatie in zit.

[GeroldM]

Jira_Clone is inderdaad beperkt. Heb het maar heel even bekeken en wat er is werkt aardig. Misschien dat de auteur ervan zaken doorpakt vanwege de Atlassian ommezwaai.

Heb in mijn vorige post nu ook links naar Fossil toegevoegd. Kan interessanter voor je zijn dan je op het eerste gezicht zou zeggen. Authenticatie is in elk geval geen probleem.

[dok33]

Ik kan me niet zo goed voorstellen dat iemand Atlassian specifiek alleen gebruikt als git reposerver
Lijkt me dat juist hun ticket systeem en scrumboards alsook hun 'wiki' Confluence vooral veel in gebruik zijn. En dan gooi je misschien je code ook maar in een Atlassian product.

Maar als je specifiek iets anders dan Github zoekt, lijkt me Gitlab de juiste weg (Nederlands ook nog, van oorsprong). Maar daar is dan wel net de issue tracking e.d. subpar. Maar wel weer fijne CI/CD integratie

[Pikkemans]

Ja.. dat is inderdaad een dingetje... Waarschijnlijk zit er voor ons niks anders op dan over te stappen op data center.

Het frappante eraan is het feit dat je gewoon de nieuwe licentie sleutel kan invoeren in je huidige jira server instantie en je in één keer alle DC features unlocked...

[Reactie gewijzigd door Pikkemans op 25 juli 2024 04:23]

[HenkEisDS]

Goeie tip, maar bizar dat het nodig is. Jira is bij ons ook niet vooruit te branden en we hebben denk ik nog geen 2000 issues in de backlog/sprint.

[GeroldM]

Heb het hier lokaal draaien op een oud Windows barrel met een AMD (A10 7800) CPU, 1 TByte HDD en 16GByte aan RAM, via een 1GBit/sec netwerk (met Cat5e bekabeling) en PostgreSQL 10 database op een Linux computer.

Loopt erg vlot met bijna 15.000 issues verdeeld over 8 projecten, waarvan 1 project er bijna 12.000 issues zijn aangemeld.

Deze server managed ook een virtuele GitLab server.

[RoestVrijStaal]

Toch vind ik het bedenkelijk dat minimaal 8GB RAM nodig is om het te draaien.

Mijn ervaring met zowel "selfhosted" als "draaiende in Atlassian's Cloud" dat je per team, per project noch per gebruiker geen "features" kan uitzetten die toch niet worden gebruikt. En dus doelloos resources blijven vreten.

[GeroldM]

Mijn gebruiker heeft genoeg rechten om features uit te schakelen. En deze verdwijnen dan ook.

Noot: Ik gebruik Jira alleen als issue tracker (on-premise). Er zijn dus geen andere Atlassian onderdelen geinstalleerd/beschikbaar.

Toegegeven, in een bare metal Linux computer met maar 4 GByte en een HDD was het niet vooruit te branden. Daarna uitgeprobeerd op een Windows barrel waar 16 GByte en een SSD in hing. Werkte uitstekend, in het begin tenminste. Zodra dit systeem een andere intensieve taak voor een korte periode uitvoerde, werd Jira opnieuw traag. Ook als die taak stopte, bleef Jira traag.

Daarna de Jira DB teruggezet naar de Linux doos en alle snelheidsproblemen verdwenen als sneeuw voor de zon.

Misschien is het voor jou ook beter om je Jira installatie zodanig uit elkaar te trekken dat je het op verschillende systemen host. DB op de ene machine, Jira software op een andere machine, de attachments op een (dedicated) file-server? Of dat nu Windows of Linux machines zijn, zou niet moeten boeien. Had deze computers simpelweg tot mijn beschikking, dat is de enige reden erachter.

[Verwijderd]

klopt maar ik blijf het belachelijk vinden hoe ziek veel resources het eet; zoiets zou 10x kleiner (qua ram) moeten kunnen als je puur kijkt naar functionaliteit

[Cergorach]

Selfhosted of Saas? Als het SaaS ik kan ik me de klacht voorstellen, maar dan vraag ik me nog steeds af of het een resource issue is of een software issue.

[geeMc]

Wij gebruiken in ieder geval de SaaS versie van Jira en die is werkelijk niet vooruit te branden. Erg jammer want de functionaliteit van het pakket is over de jaren mooi volwassen geworden.

[Martinspire]

Is dat laatste relevant? Ze hebben gewoon hun spulletjes niet op orde. Daar mag je ze best op afbranden

[Cergorach]

Natuurlijk is dat relevant! Als het en resource issue is, dan is Jira/Bitbucket niet traag, maar de hardware waar het op draait en dat is relatief eenvoudig op te lossen. Bij Atlassian als het SaaS is of bij jezelf als het selfhosted is. Natuurlijk is dan de vraag of het effectief geschreven software is, maar wat ik lees is dat het bij de andere Enterprise oplossingen niet hetzelfde issue hebben.

Over het algemeen is het niet zozeer de tool die 'bagger' is, maar dat het 'bagger' is ingericht en/of dat de gebruiker niet volgens het gedefinieerde (door de organisatie) proces wil werken.

[ropstah]

Github vs Bitbucket is inderdaad wat lastig nog. Maar of Github dan dé oplossing is...

Wat issue-tracking en wiki functionaliteit betreft en integratie en workflow vind ik Atlassian superieur en de ontwikkelingen qua performance zijn de afgelopen maanden ook vrij positief...

[SillieWous]

Op welk gebied vind je dan dat Github beter is? Ik vind namelijk Github juist het minst prettig om mee te werken vergeleken met Bitbucket en GitLab. Voor mij is de volgorde GitLab, Atlassian en dan Github.

[PainkillA]

dit is ook mijn ervaring. Gitlab gaat niet alleen kwa UI/UX github voorbij maar ook in de veel uitgebreidere CI/CD en environment mogelijkheden. Github voelt aan alsof het 10 jaar oud is en waar toch nog even snel github actions (ci/cd achtig spul) tegenaan is gegooid en toen vonden ze het wel weer mooi geweest

[jimshatt]

Wie is hier alles off-topic aan het modden? (Oké dit is off-topic maar ik wou het even kwijt)

[GeroldM]

Inderdaad, als een server zowiezo aan het internet is gekoppeld, dan is het raadzaam om er eerst een load-balancer en/of proxy server ervoor te zetten.

Zonder overweging alles maar aan het internet hangen, dan ben je minder goed bezig dan dat je zelf denkt.

[Cergorach]

Waarom is het een bagger systeem?

[geeMc]

Ga je ook nog onderbouwen waarom?

[GeroldM]

Jira is geen bagger systeem. Met de standaard instellingen zal het niet voldoen aan jouw specifieke workflow. Dat zal je probleem vast zijn geweest.

Jira zodanig configureren dat het wel goed in je workflow past, is niet makkelijk. Tenminste, totdat het befaamde "kwartje" valt. Daarna valt er goed mee te werken. Gebruik Jira als issuetracker zelf al 10 jaar en naar volle tevredenheid.

[djwice]

Voer er een dependency scan op uit die ook front-end mee neemt in de scan en je zult wellicht een andere mening hebben over de kwaliteit van het systeem, zeker als je daarnaast ook alle dependencies tegen CVE-lijsten gaat houden.

En vraag je ook af; wil ik een systeem
* dat van elke library zo veel verschillende versies nodig heeft?
* waarin security patches/updates voor een aantal frequent gebruikte onderdelen al ruim 5 jaar niet zijn uitgevoerd.

[s.stok]

JIRAsic Park