On Saturday September 10 2016 08:45:38 Jeremy Huddleston Sequoia wrote: > Yes, for most cases we would probably not need root access at activation > time, but for those cases you just listed, we would. We could do a pass over > the bom to determine if root access is needed or not. The UI for handling > such a case is non-trivial. Do we prompt once for the entire run of the > process or escalate permissions for each port we encounter and then drop them > again? If 8 ports are being installed and 4 require root, that's not a good > user experience to prompt for password 4 times.
I think it'd be up to the port to indicate if it requires root privileges during the destroot. This is (implicitly) what happens with ports that create a new user or group; there's a phase that requires root (configure, I think). How's that handled at the UI level? I'm guessing that the phase will simply fail for the port(s) that don't have the appropriate privileges. > > I understand that the certificate catching is coupled to the file's inode > > (whatever that is under HFS+), and the new copy indeed had a new inode. And > > yet another inode after signing it. > > If you can reproduce this, please let me know and file a radar with details > and let me know the number, so I can followup internally on it. I haven't > seen such cases. The only issue I'm aware of is with overwriting an existing > file (eg: using cp instead of mv). To make this reproducible I'd probably be looking at the following sequence? 1) copy a binary from some original and ad-hoc sign it 2) delete it 3) copy the original once more and sign it with another certificate Correct me if I'm wrong, but I think that's what a `port -n upgrade --force` boils down to if signing is done in the post-activate, no? Is there any reason to expect that the certificate used in 3) must be a new one not yet used to sign other executables? > iOS was never branded as UNIX. It is UNIX-like, but it was never UNIX. AFAIK it is or used to be based on OS X, evidently without the userland but with a comparable kernel. Was that just a shortcut way of thinking of things? > I've got an internal 1TB SSD and it is more than enough for most of my needs. > I mainly use USB for thumbsticks and my camera. In such cases, the > throughput is bottlenecked on the attached device, not the bus. > > That being said, my server machine is a 2012 MacMini, and I've got a > DroboMini and a LaCie RAID attached to it via thunderbolt, and the throughput > and latency are more than adequate for my demanding needs. Thunderbolt external disks and 1TB SSDs are simply out of my budget. > For folks like you and me, it might be a minor concern being limited to 1TB, > but we can certainly use an external SSD or an SDXC to increase storage as > needed in the future. I see it as more than a minor concern. Not because I expect I'll ever need more than 1TB internal space, but I would certainly not feel comfortable when I know I cannot replace something that can fail that easily and unpredictable as an SSD (or HDD for that matter). I don't recall but it's quite likely too that I replaced the HDD in my current MBP with a Hitachi as soon as I received the machine. My only experience to date with SSDs was as an external. Connected over FW800 (the fastest bus I had at the time) showed 0 gain over a good HDD ... and the whole thing died catastrophically after not even 4 months. FWIW, that Clevo notebook I mentioned has an internal 2.5" disk (came with an SSHD) but even at its price point it has a fashionable slot to add an SSD. That's the kind of approach I like: adding expansion options instead of removing them. R. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
