On Apr 18, 2011, at 08:36 , Ryan Schmidt wrote:
[…]
> Ports that are not python modules but merely use python probably should only
> exist as a single port (whose name does not begin with a py*- prefix, and
> which is not in the python category) and instead have variants for each
> supported
On Apr 18, 2011, at 03:41, p...@macports.org wrote:
> Revision: 77967
> http://trac.macports.org/changeset/77967
> Author: p...@macports.org
> Date: 2011-04-18 01:41:52 -0700 (Mon, 18 Apr 2011)
> Log Message:
> ---
> updaded gource to 0.32
>
> Modified Paths:
> ---
So, let's take it that security is the cumulative property of the tools, the
process, and the hosting arrangement.
For starters, I think a fundamental question is what kind of signatures to use
and how things are signed. ASF, for example, does a pretty job of laying this
out in one page:
http:
On 04/17/2011 11:25 PM, Jordan K. Hubbard wrote:
> Perhaps a better idea would be to enhance trace mode such that it
> "faults in" stuff on demand into a run-specific staging area.
> Read-only opens of the files in the system would succeed, of course,
> it being only creations or rw/append opens wh
On Apr 18, 2011, at 1:29 AM, Thomas de Grivel wrote:
> Le 04/16/11 20:56, Jordan K. Hubbard a écrit :
>>
>> On Apr 16, 2011, at 7:59 AM, Thomas de Grivel wrote:
>>
>>> I can't believe you actually mean that. I think you do not understand the
>>> problems fixed by this security proposition. And
On 18 Apr 2011, at 06:29, Thomas de Grivel wrote:
> Le 04/16/11 20:56, Jordan K. Hubbard a écrit :
>>
>> Heh. That is an interestingly self-canceling argument. "If you are not
>> willing to go out of your way to facilitate my own unwise usage of the
>> machine in a completely unsecured enviro
On Mon, Apr 18, 2011 at 08:27, Jeff Johnson wrote:
>
> You are assuming a threat vector reasoning that starts:
> 0) assume sudo is "infected" maliciosly.
> ...
> 42) anything is possible, including other ppkgs infected and
> distributed.
>
> The answer there is not using an p
On Apr 18, 2011, at 9:27 AM, Arno Hautala wrote:
>
> So let's say you're for some reason using the MacPorts sudo instead of
> the system shipped version (maybe the system version is out of date
> and insecure). You're updating your ports at a cafe and someone spoofs
> the update for the sudo port.
On Mon, Apr 18, 2011 at 06:12, Bayard Bell
wrote:
>
> I've read back on the threads from March about binary packaging and
> appreciate better what constraints were accepted to simplify deployment. The
> signed Macports releases in distfiles that Anders pointed me to is signed
> with GPG. Given tha
On Mon, Apr 18, 2011 at 09:38, Daniel J. Luke wrote:
> On Apr 18, 2011, at 9:27 AM, Arno Hautala wrote:
>>
>> So let's say you're for some reason using the MacPorts sudo instead of
>> the system shipped version (maybe the system version is out of date
>> and insecure). You're updating your ports a
On Apr 18, 2011, at 9:27 AM, Arno Hautala wrote:
> On Mon, Apr 18, 2011 at 08:27, Jeff Johnson wrote:
>>
>> You are assuming a threat vector reasoning that starts:
>>0) assume sudo is "infected" maliciosly.
>>...
>>42) anything is possible, including other ppkgs infected
On 18 Apr 2011, at 14:48, Arno Hautala wrote:
> On Mon, Apr 18, 2011 at 09:38, Daniel J. Luke wrote:
>> On Apr 18, 2011, at 9:27 AM, Arno Hautala wrote:
>>>
>>> So let's say you're for some reason using the MacPorts sudo instead of
>>> the system shipped version (maybe the system version is out
On Mon, Apr 18, 2011 at 09:55, Jeff Johnson wrote:
>
>> So let's say you're for some reason using the MacPorts sudo instead of
>> the system shipped version (maybe the system version is out of date
>> and insecure). You're updating your ports at a cafe and someone spoofs
>> the update for the sudo
On Apr 18, 2011, at 9:40 AM, Arno Hautala wrote:
> On Mon, Apr 18, 2011 at 06:12, Bayard Bell
> wrote:
>>
>> I've read back on the threads from March about binary packaging and
>> appreciate better what constraints were accepted to simplify deployment. The
>> signed Macports releases in distfil
On Apr 18, 2011, at 10:03 AM, Arno Hautala wrote:
> On Mon, Apr 18, 2011 at 09:55, Jeff Johnson wrote:
>>
>>> So let's say you're for some reason using the MacPorts sudo instead of
>>> the system shipped version (maybe the system version is out of date
>>> and insecure). You're updating your po
On Mon, Apr 18, 2011 at 10:02, Bayard Bell
wrote:
>
> I think we need to temper how the examples are flying: an evil network
> operator can do egregious damage, but macports isn't exactly the thing end of
> the wedge for exploiting the implied level of trust.
True. Outlandish examples can be sa
On 18 Apr 2011, at 15:04, Jeff Johnson wrote:
> What is the basis for "attractive" or not?
I should be clear about this: if we want greater security these are things that
need to be decided, and this isn't a question of some set of completely
self-evident technical merits for which patches can
On Mon, Apr 18, 2011 at 10:04, Jeff Johnson wrote:
>
> On Apr 18, 2011, at 9:40 AM, Arno Hautala wrote:
>
>> I'm all for more GPG adoption, but it might be a good idea to be
>> consistent and stick with OpenSSL.
>
> These are opinions only, without any supplied reason to prefer OpenPGP
> over Open
On 18 Apr 2011, at 15:11, Arno Hautala wrote:
> On Mon, Apr 18, 2011 at 10:02, Bayard Bell
> wrote:
>>
>> I think we need to temper how the examples are flying: an evil network
>> operator can do egregious damage, but macports isn't exactly the thing end
>> of the wedge for exploiting the impl
On Apr 18, 2011, at 10:11 AM, Arno Hautala wrote:
> On Mon, Apr 18, 2011 at 10:02, Bayard Bell
> wrote:
>>
>> I think we need to temper how the examples are flying: an evil network
>> operator can do egregious damage, but macports isn't exactly the thing end
>> of the wedge for exploiting the
On Apr 18, 2011, at 10:35 AM, Jeff Johnson wrote:
>
> On Apr 18, 2011, at 10:11 AM, Arno Hautala wrote:
>
>> On Mon, Apr 18, 2011 at 10:02, Bayard Bell
>> wrote:
>>>
>>> I think we need to temper how the examples are flying: an evil network
>>> operator can do egregious damage, but macports
I *think* this does that (corrections welcome...):
socat UNIX-LISTEN:mpchroot/private/var/run/mDNSResponder,mode=666,fork
UNIX-CONNECT:/private/var/run/mDNSResponder
But with that running, attempting to ping in the chroot just keeps
repeating these errors in system.log:
mDNSResponder[26]: 42: re
On 18 Apr 2011, at 15:55, Jeff Johnson wrote:
> Note no "key management" or "delegated trust" through signing by
> developers or other "central authority" other than what the build system
> chooses to use, thereby simplifying the needed deployment.
>
> And its the "build system" not the upstream
On Mon, Apr 18, 2011 at 10:35, Jeff Johnson wrote:
>
> The actual implementation goes something like this:
> a keypair is generated
> just built packages are
> a) include the pubkey
> b) signed with the private key
> and the private key is discard
On Apr 18, 2011, at 11:14 AM, Bayard Bell wrote:
> On 18 Apr 2011, at 15:55, Jeff Johnson wrote:
>
>> Note no "key management" or "delegated trust" through signing by
>> developers or other "central authority" other than what the build system
>> chooses to use, thereby simplifying the needed dep
On Apr 18, 2011, at 3:42 AM, Rainer Müller wrote:
> On 04/17/2011 11:25 PM, Jordan K. Hubbard wrote:
>> Perhaps a better idea would be to enhance trace mode such that it
>> "faults in" stuff on demand into a run-specific staging area.
>> Read-only opens of the files in the system would succeed, of
On Apr 18, 2011, at 11:25 AM, Arno Hautala wrote:
> On Mon, Apr 18, 2011 at 10:35, Jeff Johnson wrote:
>>
>> The actual implementation goes something like this:
>>a keypair is generated
>>just built packages are
>>a) include the pubkey
>>b) signed
On Mon, Apr 18, 2011 at 11:34, Jeff Johnson wrote:
>
> You asked what other systems are in use. I replied. If you
> don't like what is implemented, all I can say is
> Patches cheerfully accepted.
I asked what systems are in use in order to investigate options for MacPorts.
I'm pointing out
On 18 Apr 2011, at 16:26, Jeff Johnson wrote:
>> There's already been some references to having some kind of automated build
>> service/sausage factory. Could you provide more info about how this is done
>> with rpm at Red Hat?
>
> Disclaimer:
> I haven't been associated with Red Hat sinc
On Sat, Apr 16, 2011 at 7:19 PM, Ryan Schmidt wrote:
> Sending reply back to list...
>
> On Apr 16, 2011, at 07:57, Eric A. Borisch wrote:
>
>> On Sat, Apr 16, 2011 at 6:17 AM, Ryan Schmidt wrote:
+variant llvm description "Use llvm compiler" {
+ configure.compiler llvm-gcc-4.2
On Apr 18, 2011, at 12:04 PM, Arno Hautala wrote:
> On Mon, Apr 18, 2011 at 11:34, Jeff Johnson wrote:
>>
>> You asked what other systems are in use. I replied. If you
>> don't like what is implemented, all I can say is
>>Patches cheerfully accepted.
>
> I asked what systems are in use
On Apr 18, 2011, at 12:36 PM, Jeff Johnson wrote:
>
> And a generated keypair with the private key discarded and
> the public key registered with time stamp differs ... how?
Where is the public key registered? Does the end-user installer do something
like:
1. Check that the public key in the pa
On Apr 18, 2011, at 12:23 PM, Bayard Bell wrote:
> On 18 Apr 2011, at 16:26, Jeff Johnson wrote:
>
>>> There's already been some references to having some kind of automated build
>>> service/sausage factory. Could you provide more info about how this is done
>>> with rpm at Red Hat?
>>
>> Dis
On Apr 18, 2011, at 12:45 PM, Daniel J. Luke wrote:
> On Apr 18, 2011, at 12:36 PM, Jeff Johnson wrote:
>>
>> And a generated keypair with the private key discarded and
>> the public key registered with time stamp differs ... how?
>
> Where is the public key registered? Does the end-user instal
On 18 Apr 2011, at 17:45, Jeff Johnson wrote:
>> Sorry, there's a gap in explicitness here. What's done to prevent the
>> robo-signer and/or build system from accepting arbitrary content? This isn't
>> relying on a trusted network, presumably there's some idea of who's allowed
>> to request a b
On Apr 18, 2011, at 1:02 PM, Bayard Bell wrote:
> On 18 Apr 2011, at 17:45, Jeff Johnson wrote:
>
>>> Sorry, there's a gap in explicitness here. What's done to prevent the
>>> robo-signer and/or build system from accepting arbitrary content? This
>>> isn't relying on a trusted network, presuma
On Mon, Apr 18, 2011 at 12:36, Jeff Johnson wrote:
>
> On Apr 18, 2011, at 12:04 PM, Arno Hautala wrote:
>
>> On Mon, Apr 18, 2011 at 11:34, Jeff Johnson wrote:
>>>
>>> You asked what other systems are in use. I replied. If you
>>> don't like what is implemented, all I can say is
>>> Patch
On Apr 18, 2011, at 1:00 PM, Jeff Johnson wrote:
>
>> Where is the public key registered? Does the end-user installer do something
>> like:
>
> In the scheme I outline, the package itself "registers" the pubkey.
I was actually interested in how/where the package registers the pubkey (and
also
On Apr 18, 2011, at 1:15 PM, Arno Hautala wrote:
>
>> There are no XSS threats in most cases for "package management"
>> because the delivery is usually from static content on mirrors,
>> not from some dynamic store. Even if "packages" are delivered from
>> a "web server" the attack is against t
On Apr 18, 2011, at 1:39 PM, Daniel J. Luke wrote:
> On Apr 18, 2011, at 1:00 PM, Jeff Johnson wrote:
>>
>>> Where is the public key registered? Does the end-user installer do
>>> something like:
>>
>> In the scheme I outline, the package itself "registers" the pubkey.
>
> I was actually inte
On Apr 18, 2011, at 1:50 PM, Jeff Johnson wrote:
>
>> so if someone wants to maliciously inject a package, he/she would have to
>> impersonate the private SKS keyserver in order to be successful, right? I
>> haven't run a keyserver, and am not really familiar with the protocol
>> implementation
On Apr 18, 2011, at 1:54 PM, Daniel J. Luke wrote:
> On Apr 18, 2011, at 1:50 PM, Jeff Johnson wrote:
>>
>>> so if someone wants to maliciously inject a package, he/she would have to
>>> impersonate the private SKS keyserver in order to be successful, right? I
>>> haven't run a keyserver, and
On Apr 18, 2011, at 2:01 PM, Jeff Johnson wrote:
>
> Differentiating a 3rd party package that originated outside of
> The One True Build System needs either a trusted time stamp
how does a trusted time stamp tell you that the origin wasn't from the one true
build system?
> (which has persistent
On Apr 18, 2011, at 2:16 PM, Daniel J. Luke wrote:
> On Apr 18, 2011, at 2:01 PM, Jeff Johnson wrote:
>>
>> Differentiating a 3rd party package that originated outside of
>> The One True Build System needs either a trusted time stamp
>
> how does a trusted time stamp tell you that the origin wa
On Apr 18, 2011, at 2:29 PM, Jeff Johnson wrote:
>
> On Apr 18, 2011, at 2:16 PM, Daniel J. Luke wrote:
>> On Apr 18, 2011, at 2:01 PM, Jeff Johnson wrote:
>>>
>>> Differentiating a 3rd party package that originated outside of
>>> The One True Build System needs either a trusted time stamp
>>
>>
On Apr 18, 2011, at 2:40 PM, Daniel J. Luke wrote:
>
> I'm asking about creepy uncle joe's skanky package build system that the
> local coffee shop network has been set up to make look like it's the product
> of the official build system.
>
Creepy uncle joe's skanky build system is detectabl
On Sun, Apr 17, 2011 at 04:01:37AM -0500, Ryan Schmidt wrote:
> On Apr 17, 2011, at 02:48, sai...@macports.org wrote:
>
> > Revision: 77907
> > http://trac.macports.org/changeset/77907
> > Author: sai...@macports.org
> > Date: 2011-04-17 00:48:17 -0700 (Sun, 17 Apr 2011)
> > Log Mes
On Apr 18, 2011, at 3:11 PM, Jeff Johnson wrote:
>
> On Apr 18, 2011, at 2:40 PM, Daniel J. Luke wrote:
>> I'm asking about creepy uncle joe's skanky package build system that the
>> local coffee shop network has been set up to make look like it's the product
>> of the official build system.
>
On Apr 18, 2011, at 3:42 AM, Rainer Müller wrote:
> Trace mode relies on DYLD_INSERT_LIBRARIES being passed to children in
> the environment. Then the loader overrides the syscall wrappers from
> libSystem with our own implementation.
>
> From a security perspective it would be quite easy to bre
On Apr 18, 2011, at 6:42 PM, Daniel J. Luke wrote:
> On Apr 18, 2011, at 3:11 PM, Jeff Johnson wrote:
>>
>> On Apr 18, 2011, at 2:40 PM, Daniel J. Luke wrote:
>>> I'm asking about creepy uncle joe's skanky package build system that the
>>> local coffee shop network has been set up to make look
On Apr 18, 2011, at 22:07, mcalh...@macports.org wrote:
> Revision: 77990
> http://trac.macports.org/changeset/77990
> Author: mcalh...@macports.org
> Date: 2011-04-18 20:07:31 -0700 (Mon, 18 Apr 2011)
> Log Message:
> ---
> openjpeg: Fix inability to copy .dSYM directory w
On Apr 18, 2011, at 22:09, Ryan Schmidt wrote:
> On Apr 18, 2011, at 22:07, mcalh...@macports.org wrote:
>
>> Revision: 77990
>> http://trac.macports.org/changeset/77990
>> Author: mcalh...@macports.org
>> Date: 2011-04-18 20:07:31 -0700 (Mon, 18 Apr 2011)
>> Log Message:
>> --
Does the MacPorts dejagnu package work for anyone? Using a fresh
installation of MacPorts
on Snow Leopard, if I execute...
sudo port -d -k install gcc45
sudo port install expect
sudo port install dejagnu
and 'cd' into the build directory from the gcc45 package build, I find that...
sudo csh
53 matches
Mail list logo
