I'd add to that that it seems to make for undue confusion to use a variant to
follow a different version.
On 10 May 2011, at 01:11, Joshua Root wrote:
> On 2011-5-10 08:34 , David Bruce wrote:
>> Hi,
>>
>> All of the SCM fetch types are discouraged in the manual for
>> "non-reproducible builds"
On 22 Apr 2011, at 06:02, Thomas de Grivel wrote:
> "Remote execution of arbitrary code" ? I picked sudo as an example but
> without signing it is also possible to replace any package to run any code
> and install it in the system as setuid if the Makefile says so. sudo is just
> more discreet
On 19 Apr 2011, at 14:12, Rainer Müller wrote:
> On 04/18/2011 04:04 PM, Jeff Johnson wrote:
>>
>> On Apr 18, 2011, at 9:40 AM, Arno Hautala wrote:
>>
>>> On Mon, Apr 18, 2011 at 06:12, Bayard Bell
>>> wrote:
>>>>
>>>> I&#x
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 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 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 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
>&
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 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 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
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 7 Apr 2011, at 19:47, Anders F Björklund wrote:
> Bayard Bell wrote:
>
>> At the risk of being a broken record, this doesn't solve MITM, which is a
>> substantial problem in the current architecture. A major difference in the
>> way that package managers with s
On 7 Apr 2011, at 20:14, Daniel J. Luke wrote:
> On Apr 7, 2011, at 3:12 PM, Bayard Bell wrote:
>>
>> On 7 Apr 2011, at 19:43, Daniel J. Luke wrote:
>>> On Apr 7, 2011, at 2:31 PM, Bayard Bell wrote:
>>>>
>>>> At the risk of being a br
On 7 Apr 2011, at 19:43, Daniel J. Luke wrote:
> On Apr 7, 2011, at 2:31 PM, Bayard Bell wrote:
>>
>> At the risk of being a broken record, this doesn't solve MITM, which is a
>> substantial problem in the current architecture.
>
> I presume you mean the cu
On 7 Apr 2011, at 10:46, Anders F Björklund wrote:
> Or just leave the archives with their +PORTFILE as they are,
> and just treat the packages like an exported "lossy" format ?
> The .tbz2.rmd160 should be "good enough" to go, and certainly
> better than blocking the *real* goal of delivering bi
I've been chewing on how to tackle the security issues I've attempted to lay
out previously, including what feedback I've already received from Rainer in
particular. Hoping to carry the conversation forward, I'd like to float the
following for feedback.
1) changing the privilege levels in macpo
On 30 Mar 2011, at 09:23, Rainer Müller wrote:
>> I'd like to see a profile,
>> test, fingerprint, and, sign implementation to provide more robust
>> comparisons between builds or even update decisions (e.g. I built on
>> this platform, with these deveopment tools, against a code base with
>> thi
#x27;s no straightforward way
to support functionality I'd consider basic like GPG/PGP signature and
encryption, I don't see that iOS has a solution adequate on its own terms.
Cheers,
Bayard
On 3 Apr 2011, at 00:01, Jordan K. Hubbard wrote:
>
> On Mar 29, 2011, at 3:51 PM, Bayard
Rainer,
I'm limited my responses to security issues, where I'm working to understand
the design and implementation by reading your comments with the existing code.
I'll attempt to answer your two other questions in a separate mail. I'm still
trying to understand how the security problems are de
Hello,
I've been somewhat active on MacPorts previously and am interested in becoming
more active via GSoC 2011 in particular.
Here's a little bit about me: I worked for nine years at a financial sector
multinational in a variety of roles in Unix infrastructure. Ours was a pretty
interesting U
20 matches
Mail list logo
