<div dir="ltr">Hey Rainer,<div><br></div><div>Sorry to get back to you so late, I was a bit preoccupied yesterday. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">That's right. I don't think it is unsolvable, just a lot of work to</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">figure it out, but the solution we implement here could also be used for</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">other applications. It might be worth the effort to have this.</span></blockquote><div><br></div><div>I'm not sure too many other people would be able to benefit from it as the issues we're having isn't so much with automatically generating a self-signed certificate (that part is already written), but getting that to work within the MacPorts build system. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">There would not be any new functionality in the graphical frontend that</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">could not also be exploited in 'sudo port' from the command line, right?</span></blockquote><div><br></div><div>I'm not sure what you mean by that. Would you mind rewording it?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">Would I have to type 'sudo pallet'? Will I be able to start the</span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">application from an app bundle?</span> </blockquote><div><br></div><div>Currently yes, unless there's a way to launch an app bundle with superuser privileges that I'm unaware of. </div><div><br></div><div>Thanks for the comments,</div><div>-Kyle</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 6:01 AM, Rainer Müller <span dir="ltr"><<a href="mailto:raimue@macports.org" target="_blank">raimue@macports.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Kyle,<br>
<span class=""><br>
On 2015-08-05 20:14, Kyle Sammons wrote:<br>
> ** Option 0: Do nothing; leave the current code in place, but continue<br>
> to ignore it; require the user to run it with superuser privileges;<br>
><br>
> Pros:<br>
> --------<br>
> 1. Easiest to implement; requires no changes to the current code,<br>
> allowing me to add more features to Pallet, and remove more bugs.<br>
><br>
> Cons:<br>
> --------<br>
> 1. Still requires a certificate. Using a modern authorization framework<br>
> requires the use of a self-signed certificate, which highly complicates<br>
> the project build process, making writing a Portfile much harder.<br>
<br>
</span>That's right. I don't think it is unsolvable, just a lot of work to<br>
figure it out, but the solution we implement here could also be used for<br>
other applications. It might be worth the effort to have this.<br>
<span class=""><br>
> 2. Still requires running Pallet with superuser privileges.<br>
><br>
> 3. Insecure. The entire application will be running as a superuser, so<br>
> any vulnerabilities that are exploitable will allow a hacker to run as<br>
> root.<br>
<br>
</span>There would not be any new functionality in the graphical frontend that<br>
could not also be exploited in 'sudo port' from the command line, right?<br>
<span class=""><br>
> ** Option 2. Remove all authorization frameworks from Pallet, and<br>
> require the user to run it with superuser privileges:<br>
><br>
> Pros:<br>
> --------<br>
> 1. Pretty easy to implement. I could implement this solution in a day or<br>
> two, allowing me to add more features to Pallet, and remove more bugs.<br>
><br>
> 2. Doesn't require a certificate. Using a modern authorization framework<br>
> requires the use of a self-signed certificate, which highly complicates<br>
> the project build process, making writing a portfile much harder.<br>
><br>
> 3. Easiest to support. Running an application with "sudo" will really<br>
> never be deprecated, and will work on every OS X version.<br>
<br>
</span>Would I have to type 'sudo pallet'? Will I be able to start the<br>
application from an app bundle?<br>
<span class=""><br>
> 4. Smallest code-base.<br>
><br>
> Cons:<br>
> ---------<br>
> 1. Insecure. The entire application will be running as a superuser, so<br>
> any vulnerabilities that are exploitable will allow a hacker to run as<br>
> root.<br>
<br>
</span>See above.<br>
<span class="HOEnZb"><font color="#888888"><br>
Rainer<br>
</font></span></blockquote></div><br></div>