Re: Please review wip/iodine

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Tue, 7 Aug 2012 00:25:45 +0200
Moritz Wilhelmy <ml+pkgsrc%wzff.de@localhost> wrote:

> On Mon, Aug 06, 2012 at 18:13:18 -0400, Matthew Mondor wrote:
> > On Mon, 06 Aug 2012 14:22:47 -0400 Greg Troxel <gdt%ir.bbn.com@localhost> 
> > wrote:
> > > It sounds like iodine needs a config file to get this from, but that's
> > > an upstream bug.
> 
> Well, it works fine the way it does, so I'd say it doesn't need anything
> per se...
> 
> > Considering that its not rare for distributions to provide config files
> > for tools, it would also be possible to provide example configuration
> > file(s) in files/ and to install it/them under examples/ at
> > post-install, i.e.:
> > 
> > INSTALLATION_DIRS+=share/examples/iodine
> > 
> > post-install:
> >     ${INSTALL_DATA} ${FILESDIR}/foo.conf 
> > ${DESTDIR}${PREFIX}/share/examples/iodine/foo.conf
> > 
> > (of course these then also should be in PLIST)
> > 
> > It's also possible to then decide that one/some of the example(s)
> > should also be copied as necessary to a configuration directory (if the
> > user has custom modifications, these won't get deleted by pkg_delete or
> > overwritten by pkg_add):
> > 
> > CONF_FILES+=${PREFIX}/share/examples/iodine/foo.conf 
> > ${PKG_SYSCONFDIR}/foo.conf
> > 
> > If we do such, I'm not saying that we shoudn't recommend to the
> > upstream maintainer to also include those as part of the iodine
> > distribution in the future :)
> 
> I'd rather not include a custom config file, i.e. one not understood by
> upstream iodine. After all, this isn't debian. That is, I don't want to
> assemble command line options to iodine by reading a custom conf.d
> hierarchy and assembling it. I also hate it when the configuration
> procedure deviates from what's documented by upstream. However, I assume
> this isn't what you're proposing.

Indeed it wasn't, I assumed that it could read a configuration file,
but I was also talking about an example config file for the DNS/domain
etc.  But I only suggested possibilities, if you're the maintainer, you
decide :)

> iodine/iodined comes completely without a config file. Options are read
> entirely through command line. Upstream told me my assumption about the
> password being readable to anyone with access to ps(1) was wrong
> (because apparently they overwrite the proctitle), so I assume there

BSDs have setproctitle(3), I think that on Linux some custom argv or
environment fiddling was necessary, I have no idea for other OSs.  But
also, all of these have a race condition issue, that is, if a process
actively lists processes it has a chance of getting the full command
line before setproctitle(3) or equivalent is called.  Of course, we
also have security.curtain (NetBSD specific sysctl)...  It would seem
safer to me if it could instead read via stdin or from a config file.
But I realize you're not the original developer, perhaps that we could
simply warn about this in MESSAGE then?

Thanks,
-- 
Matt

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
pkgsrc-wip-review mailing list
pkgsrc-wip-review%lists.sourceforge.net@localhost
https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-review