Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

API keys per ongeluk op Github, na delete nog zichtbaar!

Pagina: 1
Acties:

Vraag


  • Jazco2nd
  • Registratie: augustus 2002
  • Laatst online: 19-06 19:38
*Paniek*
Mijn docker compose yml staat op github inclusief een voorbeeld .env bestand. Per ongeluk had ik dat laatste bestand vorige week geupdate met mijn eigen .env bestand, waar mijn persoonlijke variabelen in staat (wachtwoorden, API keys van mijn homeserver).
Ik heb dit bestand volledig verwijderd, de historie alles is weg online. Nu krijg ik bericht van Sendgrid dat mijn account suspended is omdat de API key op github staat.
In de mail zit een rechtstreekse link naar een github blob binnen mijn repository en inderdaad, het gewraakte .env bestand met alle gevoelige info.


Ik kan niks met dit bestand doen! Wissen kan niet, bewerken kan niet "You must be on a branch to make or propose changes to this file."

Ik ga nu als de donder al die gegevens veranderen natuurlijk, voor zover ik dat nog niet had gedaan. Maar ik wil dit bestand echt helemaal weg hebben.

git clone heeft geen nut: het bestand lijkt niet meer in mijn repository voor te komen dus wordt ook niet lokaal gedownload.

Hoe kan je zoiets compleet wissen?

Alle reacties


  • Yukkie
  • Registratie: januari 2001
  • Laatst online: 19-06 23:02

Yukkie

Vorsprung Durch Technik

Kun je niet de hele repo op private zetten of weg gooien?

We've got that ring of confidence


  • Jazco2nd
  • Registratie: augustus 2002
  • Laatst online: 19-06 19:38
Ik heb juist dat gebruikt, de BFG cleaner vorige week. Ik kan dus zelf ook niet het bestand vinden online, alleen met de rechtstreekse link die ik van Sendgrid kreeg.

edit: ik ga gewoon nog een keer die stappen volgen, maar ik heb het vorige week dus ook 2x geprobeerd om zeker te zijn dat het weg was.

[Voor 15% gewijzigd door Jazco2nd op 10-03-2021 14:56]


  • bwerg
  • Registratie: januari 2009
  • Niet online

bwerg

Internettrol

Jazco2nd schreef op woensdag 10 maart 2021 @ 14:52:
git clone heeft geen nut: het bestand lijkt niet meer in mijn repository voor te komen dus wordt ook niet lokaal gedownload.
Even voor de zekerheid: je bedoelt niet "het bestand staat niet in de laatste revision" neem ik aan?

("de historie alles is weg" impliceert dat je het goed hebt gedaan, maar toch)

Heeft geen speciale krachten en is daar erg boos over.


  • Jazco2nd
  • Registratie: augustus 2002
  • Laatst online: 19-06 19:38
bwerg schreef op woensdag 10 maart 2021 @ 15:06:
[...]

Even voor de zekerheid: je bedoelt niet "het bestand staat niet in de laatste revision" neem ik aan?

("de historie alles is weg" impliceert dat je het goed hebt gedaan, maar toch)
Klopt, het staat in geen enkele revisie als ik hier kijk waar het bestand was:
code:
1
https://github.com/username/repositoryname/blob/master/foldername/(filename)

Er is dus geen file, in geen enkele revisie.

Maar met de rechtstreekse link van sendgrid zie je gewoon nog steeds het bestand:
code:
1
https://github.com/username/repositoryname/blob/eenlangestring/foldername/filename


Ik heb zojuist weer de stappen uitgevoerd zoals die hier staan, dit keer niet BFG-Cleaner gebruikt en de stappen voor beide url paden uitgevoerd:

code:
1
2
3
4
git clone
git filter-branch --force --index-filter "git rm --cached --ignore-unmatch PATHTOFILE" --prune-empty --tag-name-filter cat -- --all
git push origin --force --all
git push origin --force --tags


en ook stap 10..

Niks veranderd. De file staat nog steeds beschikbaar via de link van Sendgrid :(

[Voor 3% gewijzigd door Jazco2nd op 10-03-2021 15:19]


  • Jazco2nd
  • Registratie: augustus 2002
  • Laatst online: 19-06 19:38
als ik via de Sendgrid link "1 stap hoger ga" staat er duidelijk "tree" in de url. Ik gebruikte helemaal geen trees, werkte altijd in de master branch. Dus er is een tree ontstaan en binnen die tree bestaat het bestand nog.. Maar als ik
code:
1
git worktree list
doe, zie ik alleen de master tree.

  • Jazco2nd
  • Registratie: augustus 2002
  • Laatst online: 19-06 19:38
Nope, heb het antwoord met de meeste stemmen (231) geprobeerd. De antwoorden daaronder komen overeen met de Github documentatie.

  • Luc45
  • Registratie: april 2019
  • Nu online
Als zulke geheime data op het internet heeft gestaan is het er bijna niet meer af te krijgen. Tuurlijk is het handig om het alsnog weg te halen, maar het is sowieso ook verstandig deze API keys te revoken en nieuwe aan te vragen. Mocht iemand ze nog ergens op het internet vinden, dan zijn ze in ieder geval ook niet meer geldig.

  • DataGhost
  • Registratie: augustus 2003
  • Nu online

DataGhost

iPL dev

Umm, dit soort data weghalen uit een version control-repo is op zichzelf al tricky, maar het weghalen uit zoekmachines, andere archivers, repo-clones en persoonlijke opslag van mensen die het al gezien hebben is zo goed als onmogelijk. Ik mis een beetje waarom je niet voor de makkelijkste optie bent gegaan, namelijk het wijzigen van je wachtwoorden en API-keys bij de betreffende services? Je moet ze sowieso als compromised beschouwen.

  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
Zoals al gezegd is, is het sowieso verstandig om de gegevens aan te passen, want het kwaad is al geschied.

Als je het toch weg wil halen zou je ook gewoon de volledige repo kunnen verwijderen, en een nieuwe aanmaken en daar de aangepaste repo zonder de gegevens naar toe pushen ( Wel zorgen dat het lokaal ook echt weg is ;) )

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • Kalentum
  • Registratie: juni 2004
  • Laatst online: 14:04
Ik ga nu als de donder al die gegevens veranderen natuurlijk, voor zover ik dat nog niet had gedaan. Maar ik wil dit bestand echt helemaal weg hebben.
Ik neem aan dat die keys al gewijzigd zijn.

Misschien dat GitHub ook nog ergens iets cached?

PVoutput


  • Jazco2nd
  • Registratie: augustus 2002
  • Laatst online: 19-06 19:38
@Luc45 @DataGhost @Woy
Dat is sowieso gedaan, helaas vandaag pas, want vorige week na de commit heb ik onmiddelijk de documentatie gevolgd om het te verwijderen. Het stond geen minuut online (ik weet nu dat good practice is het onmiddelijk allemaal te wijzigen/revoken al stond het maar een seconde online).

Nu blijkt dus dat het in een aparte tree, die ik niet kan clonen blijkbaar, al een week online stond :(

Maar is github dan zo verschrikkelijk ingewikkeld dat er geen optie is om 1 enkele commit volledig te verwijderen? Ik begrijp sowieso niet hoe de tree is ontstaan, daar ik nooit werk met trees, ik houd het simpel.

ik heb inmiddels een verzoek ingediend via Support om sensitive info te verwijderen.. https://docs.github.com/e...nformation-removal-policy

[Voor 21% gewijzigd door Jazco2nd op 10-03-2021 15:47]


  • Klippy
  • Registratie: oktober 2000
  • Laatst online: 19-06 22:29

Klippy

Still Game

Jazco2nd schreef op woensdag 10 maart 2021 @ 15:45:
[..]
Maar is github dan zo verschrikkelijk ingewikkeld dat er geen optie is om 1 enkele commit volledig te verwijderen?
[..]
git, niet github. GitHub is gewoon een git host, zoals er velen meer zijn.
Het hele doel van git is natuurlijk versiebeheer en het opbouwen van historie zodat je niks perongeluk kan verwijderen of niet kan terugdraaien bij een fout (jij zelf, maar vooral iemand anders die in je code werkt).
Dus ja, als je dat wel wil doen is dat in theorie onmogelijk zonder commandos als `git-filter-branch` die je normaal niet snel zou gebruiken want dat vervangt je hele historie. Vandaar de vele warnings.

Ben dan ook benieuwd naar die "Private Information Removal", lijkt er op dat als ik nu een fork zou maken van je repo je alsnog pech hebt.
Maar er zijn zo veel git caches dat het zoals gezegd niet veel nut zal hebben. Keys roteren en klaar.

Steam | SXQncyBhbGwgZ29vZCwgbWFuISDwn5iO


  • Kalentum
  • Registratie: juni 2004
  • Laatst online: 14:04
Jazco2nd schreef op woensdag 10 maart 2021 @ 15:45:
@Luc45 @DataGhost @Woy
Maar is github dan zo verschrikkelijk ingewikkeld dat er geen optie is om 1 enkele commit volledig te verwijderen? Ik begrijp sowieso niet hoe de tree is ontstaan, daar ik nooit werk met trees, ik houd het simpel.
Dat woordje 'tree' is een GitHub dingetje, geen git ding. Het betekent dat de GitHub website een bestandslijst (directory) gaat tonen. Dus bv tree/2342424 verwijst naar de directorystructuur in commit 2342424. Als GitHub de inhoudt van een bestand toont dan staat er 'blob'

Daar heb je verder geen invloed op.

https://git-scm.com/docs/git-worktree Git Worktree is een heel ander concept en heeft niets met wat GitHub een 'tree' noemt te maken.

dus
code:
1
 https://github.com/username/repositoryname/blob/eenlangestring/foldername/filename

'eenlangestring' is een commit hash. Als jij die commit hebt verwijderd, dan lijkt het me dat Gitthub het niet meer zou moeten tonen en dat het dus een cache issue is.

[Voor 14% gewijzigd door Kalentum op 10-03-2021 16:12]

PVoutput


  • Freeaqingme
  • Registratie: april 2006
  • Nu online
Het gaat er niet om of/dat het online gestaan heeft, laat staan hoe lang. Het gaat er om dat het gedeeld is met een derde partij. Nou zal Github niet direct iets met jouw api-keys doen, maar voor hetzelfde geldt is er net in 'die ene minuut' een backup gemaakt van die server, en wordt Github over 6 maanden gehackt, waarbij men in die backup gaat speuren.

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


  • Hydra
  • Registratie: september 2000
  • Laatst online: 11:35
Het heeft helemaal geen zin die key nog te verwijderen. Hij is al lang gescraped. De enige optie is de key blokkeren/verversen.

https://niels.nu


  • Hydra
  • Registratie: september 2000
  • Laatst online: 11:35
Freeaqingme schreef op woensdag 10 maart 2021 @ 16:21:
Het gaat er niet om of/dat het online gestaan heeft, laat staan hoe lang. Het gaat er om dat het gedeeld is met een derde partij. Nou zal Github niet direct iets met jouw api-keys doen, maar voor hetzelfde geldt is er net in 'die ene minuut' een backup gemaakt van die server, en wordt Github over 6 maanden gehackt, waarbij men in die backup gaat speuren.
Er zijn gewoon heel veel bots die die dingen scrapen om Bitcoin miners e.d. te starten op hosts. Heb het zelf zien gebeuren bij een klant; het was serieus een kwestie van minder dan een uur.

https://niels.nu


  • vikterr
  • Registratie: februari 2017
  • Laatst online: 18-05 10:36
Vreemd dat niemand vraagt of dit een publieke of private repo was. https://tecadmin.net/delete-commit-history-in-github/

of source files kopieren en nieuwe repo maken.

  • Hydra
  • Registratie: september 2000
  • Laatst online: 11:35
vikterr schreef op woensdag 10 maart 2021 @ 22:08:
Vreemd dat niemand vraagt of dit een publieke of private repo was. https://tecadmin.net/delete-commit-history-in-github/

of source files kopieren en nieuwe repo maken.
Afaik kan sendgrid dit alleen weten als het een public repo is.

https://niels.nu


  • Vloris
  • Registratie: december 2001
  • Laatst online: 14:02
Jazco2nd schreef op woensdag 10 maart 2021 @ 15:16:
[...]


Klopt, het staat in geen enkele revisie als ik hier kijk waar het bestand was:
code:
1
https://github.com/username/repositoryname/blob/master/foldername/(filename)

Er is dus geen file, in geen enkele revisie.

Maar met de rechtstreekse link van sendgrid zie je gewoon nog steeds het bestand:
code:
1
https://github.com/username/repositoryname/blob/eenlangestring/foldername/filename
Je spreekt jezelf nu tegen.
In de huidige master is het bestand niet terug te vinden, in de revisie waar sendgrid naar linkt ("eenlangestring") nog wel.

Volgens mij snap je nog niet helemaal hoe git revisies en history werken. Het feit dat een bepaalde revisie niet in de history van master zit wil nog niet zeggen dat die revisie meteen helemaal verwijderd is.

  • Kalentum
  • Registratie: juni 2004
  • Laatst online: 14:04
Ik dacht dat hij de commit had verwijderd en een force push had gedaan... maar blijkbaar niet?

PVoutput


  • Lethalis
  • Registratie: april 2002
  • Niet online
DataGhost schreef op woensdag 10 maart 2021 @ 15:38:
Umm, dit soort data weghalen uit een version control-repo is op zichzelf al tricky, maar het weghalen uit zoekmachines, andere archivers, repo-clones en persoonlijke opslag van mensen die het al gezien hebben is zo goed als onmogelijk. Ik mis een beetje waarom je niet voor de makkelijkste optie bent gegaan, namelijk het wijzigen van je wachtwoorden en API-keys bij de betreffende services? Je moet ze sowieso als compromised beschouwen.
Inderdaad. Zo snel mogelijk die API keys veranderen.

Er zijn namelijk mensen die speciale github crawlers hebben hiervoor en binnen notime die keys te pakken hebben. Dan krijg je van die leuke verhalen dat iemand ineens een heel virtueel server park heeft in zijn bezit bij AWS voor vele duizenden euro's per maand zonder dat zelf door te hebben (totdat de creditcard rekening binnenkomt).

@Jazco2nd Heb je github per se nodig trouwens? Ik zou gewoon lokaal een gitea server draaien en die lekker privé houden.

[Voor 6% gewijzigd door Lethalis op 11-03-2021 09:58]

Even a broken clock is right twice a day.


  • Hydra
  • Registratie: september 2000
  • Laatst online: 11:35
Vloris schreef op donderdag 11 maart 2021 @ 09:12:
Volgens mij snap je nog niet helemaal hoe git revisies en history werken. Het feit dat een bepaalde revisie niet in de history van master zit wil nog niet zeggen dat die revisie meteen helemaal verwijderd is.
Idd. Zelfs als je een branche pushed en daarna die hele branch verwijdert heb je nog twee problemen. 1. Het is al lang gescraped door bots. 2. het staat altijd nog in de reflog en is dus terug te vinden.

https://niels.nu


  • Hydra
  • Registratie: september 2000
  • Laatst online: 11:35
Lethalis schreef op donderdag 11 maart 2021 @ 09:55:
Er zijn namelijk mensen die speciale github crawlers hebben hiervoor en binnen notime die keys te pakken hebben. Dan krijg je van die leuke verhalen dat iemand ineens een heel virtueel server park heeft in zijn bezit bij AWS voor vele duizenden euro's per maand zonder dat zelf door te hebben (totdat de creditcard rekening binnenkomt).
Ik heb dit zelf bij een klant meegemaakt. Externe partij had deploy keys gepushed naar een publieke Git repo. In no time (echt binnen een uur) stonden er een hele berg bitcoin miners te draaien. AWS had dit zelf door en de account manager heeft het bedrijf gebeld om te melden dat dit aan de hand was. Erg netjes van ze; de klant zelf had het helemaal niet door.

https://niels.nu


  • Hydra
  • Registratie: september 2000
  • Laatst online: 11:35
Lethalis schreef op donderdag 11 maart 2021 @ 09:55:
@Jazco2nd Heb je github per se nodig trouwens? Ik zou gewoon lokaal een gitea server draaien en die lekker privé houden.
Niks mis met github. Sterker nog; als je dit soort fouten maakt vooral NIET je spullen zelf gaan draaien. Github heeft gewoon prive repos.

https://niels.nu


  • Lethalis
  • Registratie: april 2002
  • Niet online
Hydra schreef op donderdag 11 maart 2021 @ 09:59:
[...]
Niks mis met github. Sterker nog; als je dit soort fouten maakt vooral NIET je spullen zelf gaan draaien. Github heeft gewoon prive repos.
Jein (ja en nee).

Ik snap dat het slecht gedrag kan bevorderen, omdat je jezelf veilig waant met een eigen / lokale git server.

Maar je spullen liggen ook niet meteen op straat als je dan toch eens een fout maakt. Je moet dan minimaal toegang hebben tot het netwerk waar gitea op draait en gitea heeft ook gewoon private repos :) En onbeperkt, gratis en voor niets.

Je moet wel zelf je backups regelen uiteraard, maar goed... dat geldt voor alles.

PS
Wij exposen gitea niet naar het internet toe. Je moet minimaal met een VPN client verbinding maken eerst, voordat je er vanaf afstand bij kan.

[Voor 9% gewijzigd door Lethalis op 11-03-2021 10:11]

Even a broken clock is right twice a day.


  • Hydra
  • Registratie: september 2000
  • Laatst online: 11:35
Lethalis schreef op donderdag 11 maart 2021 @ 10:09:
Maar je spullen liggen ook niet meteen op straat als je dan toch eens een fout maakt.
Waarom niet? Een private repo op public zetten op github is niet makkelijker dan een soortgelijke fout maken met je eigen spul. Daarbij komt dat 'een fout' bij self-hosting kan betekenen dat je alles kwijt bent.

Ik vind het geen goed advies, sorry.

https://niels.nu


  • Lethalis
  • Registratie: april 2002
  • Niet online
Omdat we het niet direct aan het internet hangen :) Dus als je geen VPN client hebt met de juiste certificaten, kom je er überhaupt niet bij.

Grootste risico van self-hosten vind ik het maken van goede back-ups (offsite + offline / immutable). Dat moet je dus absoluut wel goed op orde hebben, mocht die dag een keer komen dat je met ransomware of iets dergelijks te maken krijgt.

Maar ik ben het met je eens dat het:
1. Slecht gedrag zou kunnen bevorderen.
2. Het betekent dat je ineens ook systeembeheerder bent (en dat wil je niet altijd zijn).

Vandaar mijn jein. Op mijn werk draaien we sowieso veel op eigen servers en zijn de back-ups al geregeld enzovoorts, dus dan speelt punt 2 wat minder een rol. Ik heb overigens wel vaak geprobeerd management ervan te overtuigen clouddiensten te gebruiken - en privé wel degelijk met github, AWS en Azure gespeeld - maar dat willen ze simpelweg niet.

Even a broken clock is right twice a day.


  • Hydra
  • Registratie: september 2000
  • Laatst online: 11:35
@Lethalis voor mij is het simpel; tenzij je als bedrijf als core business hebt een Git host te zijn, kun je het beter niet zelf beheren.

https://niels.nu


  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

Vloris schreef op donderdag 11 maart 2021 @ 09:12:
[...]

Volgens mij snap je nog niet helemaal hoe git revisies en history werken. Het feit dat een bepaalde revisie niet in de history van master zit wil nog niet zeggen dat die revisie meteen helemaal verwijderd is.
Volgens mij jij ook niet, anders zou je wel vertellen wat hij eraan kan doen?

Een niet-gereferencede commit blijft nog even hangen in Git, om zo destructieve acties toch ongedaan te kunnen maken vanuit het reflog.

Dus, TS:
The BFG will update your commits and all branches and tags so they are clean, but it doesn't physically delete the unwanted stuff. Examine the repo to make sure your history has been updated, and then use the standard git gc command to strip out the unwanted dirty data, which Git will now recognise as surplus to requirements:

$ git reflog expire --expire=now --all
$ git gc --prune=now --aggressive
Dit haalt de commit en de referenties ernaar lokaal weg, maar ... dit kun je niet pushen. Je moet wachten tot Github zelf ook een garbage collection heeft gedraaid. Dat gebeurt hooguit eens per 24 uur.

En in de tussentijd kan de hele wereld jouw API-keys lezen, dus zoals hierboven al herhaaldelijk gemeld: blokkeer ze (dat heeft Sendgrid blijkbaar al gedaan) en vraag nieuwe aan.

[Voor 9% gewijzigd door CodeCaster op 11-03-2021 10:45]

As always, we are nailed to a cross of our own construction.


  • Voutloos
  • Registratie: januari 2002
  • Niet online
Jazco2nd schreef op woensdag 10 maart 2021 @ 14:52:
Mijn docker compose yml staat op github inclusief een voorbeeld .env bestand. Per ongeluk had ik dat laatste bestand vorige week geupdate met mijn eigen .env bestand, waar mijn persoonlijke variabelen in staat (wachtwoorden, API keys van mijn homeserver).
Uit deze tekst kan ik niet helemaal opmaken welk bestand nou echt in git staat, maar voor deze zekerheid een good practice: Je wil doorgaans iets van een .env.example in git en de echte .env in je .gitignore.
Als dat de opzet is, heb je ook de extra drempel van het plakken van echte waardes richting een voorbeeldbestand. En dat moet je gewoon nooit doen. :p

Talkin.nl daily photoblog


  • Vloris
  • Registratie: december 2001
  • Laatst online: 14:02
CodeCaster schreef op donderdag 11 maart 2021 @ 10:43:
[...]

Volgens mij jij ook niet, anders zou je wel vertellen wat hij eraan kan doen?
Behalve zorgen dat de gelekte API keys nergens meer gebruikt worden zou ik adviseren er vooral niets meer mee te doen! Je kunt alleen maar meer stuk maken dan je wilt als je niet precies weet waar je mee bezig bent met dit soort trucjes met de inner-workings van git.

  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
Sowieso is het natuurlijk al een goed idee om dit soort secrets uberhaubt niet in dergelijke config files op te slaan die uit de root van je git repo gelezen worden. Gebruik liever iets als Azure Vault, AWS Secrets Manager of Kubernetes Secrets.

Als deze gegevens niet uit dergelijke files gelezen worden kun je ze ook niet per ongeluk comitten.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • raptorix
  • Registratie: februari 2000
  • Laatst online: 11-06 09:34
Woy schreef op donderdag 11 maart 2021 @ 14:06:
Sowieso is het natuurlijk al een goed idee om dit soort secrets uberhaubt niet in dergelijke config files op te slaan die uit de root van je git repo gelezen worden. Gebruik liever iets als Azure Vault, AWS Secrets Manager of Kubernetes Secrets.

Als deze gegevens niet uit dergelijke files gelezen worden kun je ze ook niet per ongeluk comitten.
Dit dus, en door dit soort gepruts is Sendgrid niet meer fatsoenlijk te gebruiken, vorig jaar massaal geblacklist op Spamhaus :(

  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
raptorix schreef op zondag 14 maart 2021 @ 10:31:
[...]

Dit dus, en door dit soort gepruts is Sendgrid niet meer fatsoenlijk te gebruiken, vorig jaar massaal geblacklist op Spamhaus :(
Ja, ik ben er ook helemaal weg gemigreerd. De support van sendgrid was echt waardeloos. Het heeft meer dan een maand geduurd voordat er gedelist was, en binnen de kortste keren waren ze weer geblacklist. Enige reactie was dat dat blijkbaar is wat je van sendgrid mag verwachten. Daar ga ik niet voor betalen.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • raptorix
  • Registratie: februari 2000
  • Laatst online: 11-06 09:34
Woy schreef op zondag 14 maart 2021 @ 11:36:
[...]

Ja, ik ben er ook helemaal weg gemigreerd. De support van sendgrid was echt waardeloos. Het heeft meer dan een maand geduurd voordat er gedelist was, en binnen de kortste keren waren ze weer geblacklist. Enige reactie was dat dat blijkbaar is wat je van sendgrid mag verwachten. Daar ga ik niet voor betalen.
Plus dat een betaald account vrij duur is als je maar 100 mails per maand ermee stuurt, ik had het aanvankelijk op een trial van een ander product gedaan maar dacht dat dat na trial stopte (bleek niet zo te zijn ;) )

Uiteindelijk maar een apart outlook online account gebruikt.

  • igmar
  • Registratie: april 2000
  • Laatst online: 00:26

igmar

ISO20022

Jazco2nd schreef op woensdag 10 maart 2021 @ 14:52:
*Paniek*
Mijn docker compose yml staat op github inclusief een voorbeeld .env bestand. Per ongeluk had ik dat laatste bestand vorige week geupdate met mijn eigen .env bestand, waar mijn persoonlijke variabelen in staat (wachtwoorden, API keys van mijn homeserver).
Ik heb dit bestand volledig verwijderd, de historie alles is weg online. Nu krijg ik bericht van Sendgrid dat mijn account suspended is omdat de API key op github staat.
In de mail zit een rechtstreekse link naar een github blob binnen mijn repository en inderdaad, het gewraakte .env bestand met alle gevoelige info.


Ik kan niks met dit bestand doen! Wissen kan niet, bewerken kan niet "You must be on a branch to make or propose changes to this file."

Ik ga nu als de donder al die gegevens veranderen natuurlijk, voor zover ik dat nog niet had gedaan. Maar ik wil dit bestand echt helemaal weg hebben.

git clone heeft geen nut: het bestand lijkt niet meer in mijn repository voor te komen dus wordt ook niet lokaal gedownload.

Hoe kan je zoiets compleet wissen?
Als de keys op github staan zijn ze compromised. Einde verhaal, dat is niet op te lossen. Ze zijn waarschijnlijk al gescraped, en worden actief gebruikt.

Ook een eventuele opschoonactie in git zal dit niet veranderen : Die keys zijn al gescraped. Advies : Roteer je API keys, en zorg dat dit niet meer gebeurd. Werk in een deploy pipeline met placeholders, en voor locale development met environment variables.
Pagina: 1


Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Microsoft Xbox Series X LG CX Google Pixel 5a 5G Sony XH90 / XH92 Samsung Galaxy S21 5G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True