On Tue, Jun 28, 2016 at 8:38 PM, Zachary Oglesby <zach@xxxxxxxxxx> wrote: > > Thanks for the info, it sounds like the macOS application really requires a > Mac to build then as, at least in my opinion, Apple's signing process > provides the users with the easiest workflow, and the highest level of > assurance that the code is legitimate. Yes. What I'm uncertain about is what this would look like if it were shipped as a container for Docker on Mac (using HyperKit instead of Virtual Box) if there's any kind of code signing there, or if it's obviated because it's in a container and thus "safe". But then also whether the container has the necessary privilege to dd to a raw device. > Can you also provide us information on the Windows build process? No idea really. I asked a colleague who does Windows IT and he doesn't know for sure either. I think that world is much more variable. He suspects that it's possible to get a 3rd party certificate issued, signed by an intermediate certificate already included in Windows, and Windows will run binaries signed with that 3rd party cert. But... I don't know. So it might be easier than on macOS. I know there's a preference to have a native installer. But it seems fairly clear this could be a Docker or Flatpak package for Linux distros. If that's going to happen anyway, the installation of Docker on Mac (or Windows) seems a lot easier to evaluate than even the most rudimentary evaluation of either Apple or Microsoft's native app requirements. There are some very neat advantages if this could be done as a container, aside from far fewer variations between the tools. Doing the overlay setup, currently not supported in Fedora Media Writer, but desired, means having access to Linux tools to write out the necessary metadata. If this is already available in the container no matter the platform, it's easier than having to write an installer specific library to do that. And so on. -- Chris Murphy -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/security@xxxxxxxxxxxxxxxxxxxxxxx