Moritz Wilhelmy <ml+pkgsrc%wzff.de@localhost> writes: > Just to clarify to everyone starting to read this thread just now, and > wondering what we're discussing: > The following options are available to read the password: > > 1. Environment: IODINE_PASS and IODINED_PASS > (no idea why there have to be two variables, since you usually don't > run the server and client on the same machine) > > 2. Commandline: -P parameter > > 3. Interactively, when prompted because 1 or 2 were not supplied > > This *does* make sense for a program that does not include a config > file. I think this is the basic disagreement, and there are two things going on: You're focusing on security of the tunnel password against local users, and really the tunnel isn't that important a resource and usability is also very important. I don't object to being careful, but it seems upstream has somewhat gone down the path of thinking their particular program is important enough to deserve user brain time. Programs should be usable straigthforwardly from other programs. There might be a gnome gui network manager option to 'start iodine tunnel', and it should be able to work simply. The server side should be startable from rc.conf/rc.d so that it runs on boot. > Frankly, I don't even see the immediate need for one, especially > since the flags change depending on environment. iodine can probe some I don't follow this (but haven't managed to spend the time to set it up yet). > of them, but if a DNS setup is hopefully borked, there might be manual > intervention required. Therefore, and because of the fact that rc.conf > is (and should be) readable to all users, I think it might be best to > not supply an rc.d script. But I really don't know. I think it's better to have the option, for those who value things working straightforwardly over the risk of an untrusted local user (some systems have none) finding out a tunnel password. People who don't like it can not use it. That said, it isn't reasonable to demand that you write a script before this is moved to pkgsrc proper; I mean to be saying that in an ideal world the pkg ought to have a script (and upstream would have a config file). > Yep, I was aware of that. Putting it into MESSAGE is a good idea, > thanks. As far as I know, any means of setting the process title is > highly unportable. Also, even on NetBSD, security.curtain is not set by > default. I think this is an overuse of MESSAGE for things that don't really warrant it. These sorts of problems are common and I think pkgsrc should be sparse about lecturing users. So, if you're in the mood to make an rc.d script, please go ahead, and if you're not, it seems this is ready to go. Thanks for putting up with my ranting.
Attachment:
pgp8b3sNRDCM8.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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