Solene Rapenne <sol...@perso.pw> wrote: > On Tue, Jun 11, 2019 at 11:55:29AM -0600, Theo de Raadt wrote: > > Bryan Steele <bry...@gmail.com> wrote: > > > > > In addition to what Stuart said, irssi is using libperl here for perl > > > scripts, which means the irssi unveil will be applied to them. There > > > are many uses for perl scripts, and many involve reading arbitrary files > > > and there's no way to know that upfront. > > > > Keep in mind unveil is different from pledge. > > > > With pledge, you get killed. Unacceptably inconvenient to have that in > > a sustained runtime, when you suddenly trigger a new feature. > > > > With unveil, a hidden file is EACCES or ENOENT therefore a deeply > > complicated feature may *subtly misbehave* if it continues operation > > in the absence of a control file or something. > > > > I think making this a getopt flag is a disaster. > > > > It was done with chrome *temporarily* during test phases, but sustained > > use of flags tied to low-level features is seriously user hostile. > > > > The following patch makes the irssi unveiled version a new flavor, with > unveil/pledge optin. I think this is best option. This is optin AND the > package name is explicit, nobody should be surprised of irssi-unveil > blocking some plugins.
I don't see the difference between a getopt flag, and a flavor. It will unexpectedly crash on a pledge violation, or act incorrectly when a file it exists to be there isn't visible. On the way to improving software security, we all need to avoid regressive user-hostile behaviours.
