Re: [139167] trunk/dports/aqua/pgAdmin3/Portfile
On Aug 5, 2015, at 8:07 AM, j...@macports.org wrote:
Revision
139167
Author
j...@macports.org
Date
2015-08-05 06:07:09 -0700 (Wed, 05 Aug 2015)
Log Message
pgAdmin3: add note to remind of the need to select current wxWidgets
Modified Paths
• trunk/dports/aqua/pgAdmin3/Portfile
Diff
Modified: trunk/dports/aqua/pgAdmin3/Portfile (139166 = 139167)
--- trunk/dports/aqua/pgAdmin3/Portfile 2015-08-05 12:13:18 UTC (rev
139166)
+++ trunk/dports/aqua/pgAdmin3/Portfile 2015-08-05 13:07:09 UTC (rev
139167)
@@ -107,6 +107,8 @@
variant with_postgresql91 requires postgresql91 description {Legacy
compatibility variant} {}
variant with_postgresql92 requires postgresql92 description {Legacy
compatibility variant} {}
+notes To build you need to: sudo port select wxWidgets wxWidgets-3.0
Notes are not displayed until after a port is installed, so this won't help the
user.
Further, ports are not supposed to rely on (nor make use of) the effects of
port select; the select mechanism is supposed to be only for the user's
convenience outside of MacPorts.
Please fix the port so it installs properly with wxWidgets-3.0 even when
wxWidgets-3.0 is not selected.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Looking for opinions on authorization frameworks for Pallet
Hey everyone, Currently I'm at a fork in the road for the Revitalizing Pallet GSoC project, and was hoping to crowd source some ideas about how to deal with the Apple authorization framework used to get super user privileges to allow 'port' to execute correctly under the hood. This task is the last major one on my GSoC queue. There are three possible roads to go down here; I don't know which one is the best or correct one, hence the crowd sourcing here. 0. Do nothing; leave the current code in place, but continue to ignore it; require the user to run it with superuser privileges; 1. Update the authorization framework pallet currently uses, and use it, requesting authorization only when needed; 2. Remove all authorization frameworks from it, and require the user to run it with superuser privileges. I've made a pros/cons list of each choice below, that I can think of. Thanks for your thoughts and opinions, -Kyle ** 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. 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. ** Option 1. Update the authorization framework pallet currently uses, and use it, requesting authorization only when needed: Pros: 1. Most secure. Uses code-signing to verify nothing has been tampered with, and runs the base executable with only user-privileges. 2. Apple approved: This is the Apple-approved way of getting superuser privileges when needed. Cons: - 1. Hardest to implement. As in, it would most likely take up the rest of the time I have left to work on this project, and even then it might not be 100% implemented. 2. Hardest to support. Apple has a new authorization framework on almost every version of OS X, meaning that I'd either have to support all of them (which is an obscene amount of work), or pick one that will eventually be deprecated in one or two OS X lifecycles, and won't work on any previous version of OS X. ** 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. 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. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: SVN authorization
On 06.08.2015 02:53 AM, Craig Treleaven wrote: I vaguely recall running an svn command to add MacPorts as a trusted server (or some-such) but I don’t recall the details. Could someone point me in the right direction? Refer to https://trac.macports.org/wiki/howto/SyncingWithSVN and specifically to Step 3 under Configuration. Mihai signature.asc Description: OpenPGP digital signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Looking for opinions on authorization frameworks for Pallet
On 06/08/2015, at 4:14 AM, Kyle Sammons wrote:
Hey everyone,
Currently I'm at a fork in the road for the Revitalizing Pallet GSoC
project, and was hoping to crowd source some ideas about how to deal
with the Apple authorization framework used to get super user privileges
to allow 'port' to execute correctly under the hood. This task is the
last major one on my GSoC queue. There are three possible roads to go
down here; I don't know which one is the best or correct one, hence
the crowd sourcing here.
Here is another possibility, which I used in Fossick… Note that I went the
command-line route and used tail -f to receive output asynchronously.
You may not need that if you have gone the other route. The guts of the
authorisation is to use AppleScript. Hope this helps.
/**
* This method uses AppleScript to run a privileged Unix script asynchronously
* in the background, with output to a file (e.g. a script containing MacPorts'
* port install software item command). The NSTask object defined above
* uses tail -f to collect the output as it occurs. The return string is nil
* if the script started OK or contains an error text if it failed. AppleScript
* is run with administrator privileges, which means that it pops up the usual
* Apple request for an admin password when installing non-Apple software.
*/
- (NSString *) runPrivilegedScript: (NSString *) filePath
output: (NSString *) outputFilePath;
---
- (NSString *) runPrivilegedScript: (NSString *) filePath
output: (NSString *) outputFilePath
{
NSDictionary * error;
NSString * script = [NSString stringWithFormat: @do shell script \
\'%@' '%@' 21 \ \
with administrator privileges \
without altering line endings,
filePath, outputFilePath];
NSLog(@SCRIPT: %@, script);
NSAppleScript * appleScript = [[NSAppleScript new] initWithSource:script];
if ([appleScript executeAndReturnError:error]) {
NSLog(@AppleScript running! '%@' '%@' 21 , filePath,
outputFilePath);
// Start the output-watcher.
self.task = [[NSTask alloc] init];
[self.task setLaunchPath:@/usr/bin/tail];
[self.task setArguments:[NSArray arrayWithObjects:
@-f, outputFilePath, nil]];
self.tailOfOutput = [NSPipe pipe];
self.errorOutput = [NSPipe pipe];
[self.task setStandardOutput: tailOfOutput];
[self.task setStandardError: errorOutput];
[self.task setStandardInput: [NSPipe pipe]]; // No standard input.
[self.task launch];
[[self.tailOfOutput fileHandleForReading] readInBackgroundAndNotify];
[[NSNotificationCenter defaultCenter]
addObserver: self
selector: @selector (receiveOutput:)
name: NSFileHandleReadCompletionNotification
object: nil];
return nil;
}
else {
NSLog(@Failed to run AppleScript!\n%@, error);
return [error description];
}
// TODO: User cancelled. is a possible error reason (i.e. hit Cancel
//instead of entering a password). OS X seems to allow unlimited
//failed attempts to enter the password.
}
0. Do nothing; leave the current code in place, but continue to ignore
it; require the user to run it with superuser privileges;
snip
Cheers, Ian W.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
SVN authorization
Hi: I migrated from 10.6 to 10.10 recently and I now want to do some work on the ports I maintain but I’ve run into a snag. Trying to run 'sudo port -v selfupdate’ results in: … --- Updating the ports tree Synchronizing local ports tree from file:///Users/craigtreleaven/mp/ports Updating '.': svn: E175002: Unable to connect to a repository at URL 'https://svn.macports.org/repository/macports/trunk/dports' svn: E175002: OPTIONS of 'https://svn.macports.org/repository/macports/trunk/dports': Server certificate verification failed: issuer is not trusted (https://svn.macports.org) Command failed: /usr/bin/svn update --non-interactive /Users/craigtreleaven/mp/ports Exit code: 1 … I vaguely recall running an svn command to add MacPorts as a trusted server (or some-such) but I don’t recall the details. Could someone point me in the right direction? Thanks, Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
