Hello Bruno, To be honest I mostly agree with you. Both attack scenarios & suggest fix part I have added because some maintainers asked me about it. Some parts of advisories Thanks for the good words about the language. I prepare are mostly static text (credits, disclosure timeline, etc.) and come from files on disk tough but after compiling the advisory I like to put it trough I like running it trough AI to add some variation and hopefully fix some language issues. I noticed that an AI has bigger „context” and often can find issues in text that are more niuanse that simple spell check in text editor can miss. Regarding the 4th issue I think It won’t be much harder for me to compile a bug report (especially when excluding some parts from advisory) using just static files that I have on disk. I considered it as potential issue in specific CI pipeline context so I have decided to report it as a security issue. Maybe that was a mistake but from my point of view at that time it was the right thing to do. Also I think „fast generation” of such reports (or even bogus) ones could be automatised using pure bash/python scrips. I know that there is a lot of such things nowadays but I don’t believe AI itself made it so much easier. At least for people with little scripting knowledge. I think it simply became more „fashionable” or it attracted people who only know how to type AI prompts…
Anyways sorry for misunderstanding. I just wanted to let you know that before I report anything I test it myself multiple times and as a human I might make a mistake and report something that is not a security issue as one. Anyway I just wanted to let you know that nothing I report is reported automatically but I try to (hopefully) improve the quality of our reports using automated tools. Regards, — Michał Majchrowicz / Offensive Security Engineer / PhD eWPTX PGP: D52A 5289 8256 006D 5E05 BAC6 79EA 0072 F4E1 9D57 AFINE sp. z o.o. Al. Jerozolimskie 146C, 02-305 Warszawa https://www.afine.com <https://www.afine.com/> > Wiadomość napisana przez Bruno Haible <[email protected]> w dniu 3 cze 2026, o > godz. 12:53: > > Hello Michał, > > Michał Majchrowicz wrote: >> Sorry for being to automatic for you :) I like to put few words before each >> advisory tough >> I have to admit I put my rambling through AI as often people have issues >> understanding me. >> I am not a native English speaker and at the same time even in my native >> language I have >> a tendency to write incoherent sentences and miss some stuff. Anyway to >> overcome my >> problems I use an „AI tool” as a kind of advanced spellchecker. Sorry if it >> annoys but it helps >> me keep things organised and overcome my limitations. > > Your English is quite good; no problem with that. > > I see two benefits with the approach of using AI tools for vulnerability > reporting: > - It can find bugs that a human would have needed more effort to find. > - It can add an exploit scenario. In the case of your 3 reports, we would > not have needed it, but you never know the maintainer's thinking in > advance. > > And I see also one drawback: > - It is so easy to write reports that are not well founded (like your 4th > one), > that maintainers can get overwhelmed. > > So, in the end, it is still your task as a reporter to focus on the real > problems > and not send reports about things which are not vulnerabilities. > >> Regarding the symlink issue I was thinking in the context of recent history >> with how people >> were using Gemini CLI in the pipeline or last Shai Halud (or whatever it was >> called) attack. >> Where problems with GitHub CI process allowed attackers to leak >> authentication tokens >> and as a result gain access to repo itself. I was thinking about a scenario >> where this issue >> is used to overwrite such tokens. > > The major problem here is the possibility to leak authentications. > > When you have two issues that, together, allow a certain exploit, try to ask > yourself whether the first or the second one can be replaced by a similar one. > If the first issue can be combined with a multitude of second issues, the > first > issue is the major problem. And vice versa. > >> During my research I often encounter issues that >> whether they are security bugs or not often depends on context. My approach >> is to report them anyway and let the developer decide the impact as in most >> cases >> I don’t have enough knowledge about project internals to decide myself. > > IMO, you should consider the context first. The Automake maintainers should > not need to have knowledge about GitHub or CI or similar stuff. > > Bruno > > >
signature.asc
Description: Message signed with OpenPGP
