Hello Kyle, On 2015-08-05 20:14, Kyle Sammons wrote: > ** Option 0: Do nothing; leave the current code in place, but continue > to ignore it; require the user to run it with superuser privileges; > > Pros: > -------- > 1. Easiest to implement; requires no changes to the current code, > allowing me to add more features to Pallet, and remove more bugs. > > Cons: > -------- > 1. Still requires a certificate. Using a modern authorization framework > requires the use of a self-signed certificate, which highly complicates > the project build process, making writing a Portfile much harder.
That's right. I don't think it is unsolvable, just a lot of work to figure it out, but the solution we implement here could also be used for other applications. It might be worth the effort to have this. > 2. Still requires running Pallet with superuser privileges. > > 3. Insecure. The entire application will be running as a superuser, so > any vulnerabilities that are exploitable will allow a hacker to run as > root. There would not be any new functionality in the graphical frontend that could not also be exploited in 'sudo port' from the command line, right? > ** Option 2. Remove all authorization frameworks from Pallet, and > require the user to run it with superuser privileges: > > Pros: > -------- > 1. Pretty easy to implement. I could implement this solution in a day or > two, allowing me to add more features to Pallet, and remove more bugs. > > 2. Doesn't require a certificate. Using a modern authorization framework > requires the use of a self-signed certificate, which highly complicates > the project build process, making writing a portfile much harder. > > 3. Easiest to support. Running an application with "sudo" will really > never be deprecated, and will work on every OS X version. Would I have to type 'sudo pallet'? Will I be able to start the application from an app bundle? > 4. Smallest code-base. > > Cons: > --------- > 1. Insecure. The entire application will be running as a superuser, so > any vulnerabilities that are exploitable will allow a hacker to run as > root. See above. Rainer _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev