HomeSearchPrevious dayNext day

00:07:03xkey quits [Quit: WeeChat 4.9.0]
00:07:31xkey (xkey) joins
00:14:09etnguyen03 (etnguyen03) joins
00:38:11Mateon2 joins
00:40:34Mateon1 quits [Ping timeout: 268 seconds]
00:40:34Mateon2 is now known as Mateon1
00:48:53Yakov (Yakov) joins
01:07:55multisn8 quits [Quit: WeeChat 4.9.0]
01:57:19<nicolas17>nulldata: github actions strikes again?
01:58:14<nicolas17>https://nesbitt.io/2026/04/28/github-actions-is-the-weakest-link.html
02:11:53lukash984 joins
02:50:30steering|m leaves [User left]
03:00:05etnguyen03 quits [Remote host closed the connection]
03:36:01<Yakov>just looked through that blog, looks like a lot of user-error
03:37:25<Yakov>i understand if a dependency repo is already hijacked and its only derived externally by tag and not by git hash (like most github workflows) then something malicious can be pushed
03:38:39<Yakov>however using secrets within a pull_request_target (which is unsafe since it can be triggered by anyone) or not sanitizing a bash echo from a issue_comment trigger is just absurd
03:40:01<egallager>how many of these mistakes can actionlint catch? https://github.com/rhysd/actionlint
03:41:15<nicolas17>egallager: he recommends https://docs.zizmor.sh/
03:41:29<Yakov>Maybe people should just get the memo to stop vibecoding your workflows
03:42:26<nicolas17>but "it’s a slightly uncomfortable thing to say about the platform when the best available defence for GitHub Actions is a third-party linter maintained largely by one person that catches footguns GitHub put there and could remove"
03:42:38<Yakov>i've personally never tried actionlint or zizmor so i don't know how well it works but i know there are good hardening techniques you can apply on your workflow to ensure it's safe and prevent supply chain attacks (e.g. like targeting by git hash)
03:43:29<nicolas17>i've personally never tried github actions :p
03:46:11<egallager>oh wow, zizmore is a lot more verbose than actionlint is...
03:47:06<Yakov>it all boils down to 1-3 things, being wary of your scoped workflows permissions (and that is only if you use unsafe triggers), how you're targeting your depends, and what secrets you utilize (and that is also only if you use unsafe triggers)
03:47:22<nicolas17>reading that article + https://nesbitt.io/2025/12/06/github-actions-package-manager.html leaves me feeling like this is the C language
03:47:28<nicolas17>yes you *can* write secure code, but...
03:47:50<Yakov>it's 3 things that are VERY easy to look out for
03:49:59<Yakov>A good example will be https://github.com/dani-garcia/vaultwarden/blob/main/.github/workflows/release.yml, they use empty permission scopes, they hardcode dependency git hashes instead of referencing by tag, and they use secrets within specific environments
03:51:18<Yakov>cool, looks like they also automatically generate a report using zizmor
03:53:26<Yakov>they are going the extra mile since their workflow is already secure and they technically don't even need to rely on a third-party linter however this protects them by auditing future workflow changes
03:54:10<steering>Yakov: this problem long predates vibecoding, though
03:54:55<steering>if its hard to get right people will get it wrong
03:55:02<Yakov>maybe but it's still caused by user-error by not following basic security protocols
03:55:24<Yakov>i don't think it's hard, it's just the right way to do it and people don't like doing it the right way
03:55:32<steering>so is heartbleed ;)
03:55:35<nicolas17>this feels just like "the C programmer should have just checked the buffer bounds"
03:55:39<steering>^^^
03:56:14<Yakov>its not, i'd say it's more analogous to keeping the default password of your root user with ssh opened
03:56:19<steering>i dont know what a good fix is - other than maybe things like just providing the environment variables as actual environment variables or something?
03:57:04<steering>i don't think you can say it's not hard when people get it wrong all the time.
03:57:08<steering>¯\_(ツ)_/¯
03:57:22<Yakov>it's because it's fast and simple and it gets the job done
03:57:28<Yakov>being lazy != hard
03:57:30<steering>i don't think driving is hard, it's just the right way to do it and people don't like doing it the right way :)
03:58:58<Yakov>well yes, people get distracted and slack off, i don't think that's a good example though since a persons skills can decline while code stays the same
04:00:05<Yakov>provided there aren't any inherent security flaws as shown in the blog
04:01:51<Yakov>If you used Github workflows before, I think you'd agree with me that it's more equivalent to not changing the default password on your Linux machine than not checking buffer bounds (buffer bounds can be in unlimited places and in unlimited forms, while in a YAML workflow there's only one place to either write it right or wrong)
04:04:40<pabs>the good fix is to get a job at GitHub so you can fix their system to not have sharp edges :)
04:07:52<Yakov>You can never fix it because it's solely based off bad coding practices and you can't fix bad coding practices
04:09:05<Yakov>GitHub can choose to add more automatic scanners or linters that look out for this but that is something people should appreciate and not take for granted
04:10:07<Yakov>At the end of the day a programmer has free choice and I don't think it's at the fault of Github at all
04:10:25<egallager>anyways GH just so happens to be pushing a survey re: actions on me: https://survey3.medallia.com/?actions&id=1388660
04:12:51<pabs>just make GitHub Actions v2 that doesn't you let you do unsafe shit
04:13:45<Yakov>aka Rust
04:13:52<Yakov> /j
04:18:44<pabs>Rust doesn't go far enough, you need something beyond Haskell. like Idris2 or Lean or Rocq/Coq or other formal methods stuff
04:20:13<Yakov>GitHub could technically eliminate the supply chain attack vector by enforcing immutable and permanently unique release tags, but doing so would inadvertently effect any repo which isn't a workflow dependency
04:21:55HackMii quits [Remote host closed the connection]
04:22:30HackMii (hacktheplanet) joins
04:22:44<Yakov>Or alternatively they can resolve the git hash of the referenced tag at the time of the workflow commit rather than at workflow execution
04:23:05<nicolas17>lock files, as mentioned here? https://nesbitt.io/2025/12/06/github-actions-package-manager.html
04:23:07<Yakov>Still won't prevent the mistakes of mishandling unsafe workflow triggers
04:23:52<Yakov>yeah i think lockfiles is exactly how i described it
04:30:37<Yakov>The reason they didn't do that is probably because that's adding infrastructure that's outside the git eco
04:42:20<Yakov>s/The reason/A reason
04:42:28<Yakov>Since they're not gonna track and author a lock file on your behalf
04:49:06<Yakov>Also version resolving within a GitHub workflow was made with a different functionality approach that wouldn't be compatible with the existing lockfile approach, for example you can target a major version (while omiting the minor version) and as long as new releases are created under the same major version your workflow will automatically use the
04:49:06<Yakov>latest one, and people using these dependencies (that omit the minor version) expect that behavior
04:50:47<Yakov>So yeah, even the blog author suggesting the lockfile as a fix isn't as straightforward as it seems
04:54:27<Yakov>Their best option is probably just enforcing immutable and permanent unique release tags and somehow specifically only enforcing that on workflow dependency repositories
04:55:21<Yakov>That will at least protect the people who specify the exact version tag .
05:01:20<pabs>huh, haven't seen this error from Google Search before:
05:01:21<pabs>Server Error
05:01:21<pabs>We're sorry but it appears that there has been an internal server error while processing your request. Our engineers have been notified and are working to resolve the issue.
05:01:21<pabs>Please try again later.
05:01:37pabs wonders if they are vibecoding a bit too much these days
05:51:57atphoenix__ (atphoenix) joins
05:55:04atphoenix_ quits [Ping timeout: 268 seconds]
06:20:06<nicolas17>pabs: I got an OutOfMemoryError with full Java backtrace from Google Groups once (maaany years ago)
06:20:49Webuser794882 joins
06:33:21Umbire quits [Ping timeout: 268 seconds]
06:42:46Umbire joins
06:47:30nine quits [Quit: See ya!]
06:47:43nine joins
07:04:08BearFortress quits [Ping timeout: 268 seconds]
07:05:04BearFortress joins
07:07:50Umbire quits [Ping timeout: 268 seconds]
07:36:11Umbire joins
08:00:52Umbire quits [Ping timeout: 268 seconds]
08:07:38myself quits [Read error: Connection reset by peer]
08:07:48myself joins
08:55:42APOLLO03a joins
08:55:48APOLLO03 quits [Ping timeout: 268 seconds]
09:25:24chrismrtn (chrismrtn) joins
10:40:10pseudorizer quits [Quit: ZNC 1.10.1 - https://znc.in]
10:43:33pseudorizer (pseudorizer) joins
10:57:17nine quits [Ping timeout: 268 seconds]
10:59:00nine joins
11:02:43Bleo1826007227196234552220110 joins
11:02:53nine quits [Client Quit]
12:06:47nine joins
12:48:57Umbire joins
12:49:44Umbire quits [Remote host closed the connection]
12:50:07Umbire joins
12:59:11Umbire is now known as RJHacker86616
12:59:11RJHacker86616 quits [Killed (vindobona.hackint.org (Nickname regained by services))]
12:59:14Umbire (Umbire) joins
12:59:52Umbire quits [Remote host closed the connection]
13:00:15Umbire joins
13:01:02multisn8 (multisn8) joins
14:58:51VerifiedJ7 quits [Quit: The Lounge - https://thelounge.chat]
14:59:43VerifiedJ7 (VerifiedJ) joins
15:07:28SootBector quits [Remote host closed the connection]
15:08:38SootBector (SootBector) joins
16:05:34midou quits [Ping timeout: 268 seconds]
16:07:20midou joins
16:17:56nine quits [Quit: See ya!]
16:18:08nine joins
17:45:45Webuser794882 quits [Quit: Ooops, wrong browser tab.]
17:48:33Webuser280899 joins
18:02:47nine quits [Ping timeout: 268 seconds]
18:04:28nine joins
18:09:31nine quits [Ping timeout: 268 seconds]
18:12:11nine joins
18:45:01SootBector quits [Remote host closed the connection]
18:45:34Webuser280899 quits [Client Quit]
18:46:11SootBector (SootBector) joins
18:47:05pseudorizer quits [Quit: ZNC 1.10.2 - https://znc.in]
18:49:07pseudorizer (pseudorizer) joins
18:49:39Umbire quits [Ping timeout: 268 seconds]
19:03:50^ quits [Ping timeout: 268 seconds]
19:03:55^ (^) joins
19:13:47Umbire joins
19:14:24Umbire quits [Remote host closed the connection]
19:14:46Umbire joins
19:53:32gatagoto (gatagoto) joins
20:12:04<eggdrop>[remind] arkiver: Write Lua for manual Wget-AT jobs.
20:19:06^ quits [Remote host closed the connection]
20:19:18^ (^) joins
20:34:14SootBector quits [Remote host closed the connection]
20:35:16SootBector (SootBector) joins
21:23:55<Doranwen>I'I've apparently blundered with some of the code that is supposed to strip the LJ referers so I can get the links to other sites to be able to feed into the #// bot - because when I try it it doesn't remove a thing, yet regex101 says it matches and I've double- and triple-checked everything. I must be missing something, lol.
21:24:45<Doranwen>When I take a link like this: https://www.livejournal.com/away?to=http://photobucket.com/ and put it in, say a file I've called test3.txt (because I've been trying all manner of stuff, lol), this does nothing to the link: `sed 's~https://www\.livejournal\.com/away\?to=~~g' test3.txt > test4.txt`
21:25:12<Doranwen>I've obviously got something wrong but I can't figure out what. /o\
21:44:03<pabs>use sed -E since the default is relatively non-featureful regexes
21:46:58<pabs>or for really really featureful regexes, use perl instead of sed: perl -pe 's{foo}{bar}'
21:50:08<@JAA>Neither is needed here though. BRE is fine for that.
21:51:12<@JAA>But BRE vs ERE is indeed the cause.
21:51:54<@JAA>Doranwen: Remove the backslash before the question mark. The question mark has no special meaning in Basic Regular Expressions (BRE), which is what `sed` without options uses.
21:52:23<@JAA>Alternatively, switch to Extended Regular Expressions (ERE), where the question mark does have special meaning and needs to be escaped as you did.
21:52:42<@JAA>That'd be `-E`.
22:07:29<nicolas17>https://www.youtube.com/watch?v=Kmww5t3QW7s crazy work
22:08:04<Doranwen>Ahhhhh, that explains it.
22:08:09<Doranwen>Thank you!
22:08:22HackMii quits [Ping timeout: 240 seconds]
22:10:47HackMii (hacktheplanet) joins
22:23:45SootBector quits [Remote host closed the connection]
22:24:56SootBector (SootBector) joins
22:45:22HackMii quits [Ping timeout: 240 seconds]
22:47:34Hackerpcs quits [Remote host closed the connection]
22:47:34HackMii (hacktheplanet) joins
22:48:27Hackerpcs (Hackerpcs) joins
22:51:57Meli quits [Ping timeout: 268 seconds]
23:03:44SootBector quits [Remote host closed the connection]
23:04:45HackMii quits [Remote host closed the connection]
23:04:51SootBector (SootBector) joins
23:05:54HackMii (hacktheplanet) joins
23:25:24Meli (Meli) joins
23:38:14<Yakov>https://tanstack.com/blog/npm-supply-chain-compromise-postmortem
23:39:30<Yakov>Crazy how we were just discussing github action supply chain attacks yesterday and another major one just happened
23:40:08<Yakov>> On 2026-05-11 between 19:20 and 19:26 UTC, an attacker published 84 malicious versions across 42 @tanstack/* npm packages by combining: the pull_request_target "Pwn Request" pattern, GitHub Actions cache poisoning across the fork↔base trust boundary, and runtime memory extraction of an OIDC token from the GitHub Actions runner process.
23:43:28<Yakov>poisoning cache is a pretty crazy method

HomeSearchPrevious dayNext day