On 04/22/11 16:14, Bayard Bell wrote:
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 th
s 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 as it already is setuid.
Unless you ensure some trust with the sources, for example by signing
them with public crypto, you are fetching, compiling, and using code
from a source possibly unknown to MacPorts.
--
Thomas de Grivel
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
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 this limited audience is the
one reading here, you're tal
Le 04/16/11 16:59, Thomas de Grivel a écrit :
Le 04/13/11 21:30, Jordan K. Hubbard a écrit :
On Apr 13, 2011, at 1:15 AM, Thomas de Grivel wrote:
Lol Jordan
This man comes with a sound project, basically laying out in nice
words all the needed separate steps to provide port security and you
Le 04/13/11 21:30, Jordan K. Hubbard a écrit :
On Apr 13, 2011, at 1:15 AM, Thomas de Grivel wrote:
Lol Jordan
This man comes with a sound project, basically laying out in nice words all the
needed separate steps to provide port security and you just basically TL;DR him
saying it will fuck
Sorry Bayard I misread your name.
Le 04/13/11 10:15, Thomas de Grivel a écrit :
Lol Jordan
This man comes with a sound project, basically laying out in nice words
all the needed separate steps to provide port security and you just
basically TL;DR him saying it will fuck-never happen ?
Most of
ly left an overkill taste in your mouth. I'll join Jordan on this one.
I think 1 and 2 are outstanding issues in MacPorts and not so hard given
the huge benefit. 3 and 4 would need more discussion but are good ideas.
Anyway, just my 2¢. Let's hope that security on a Mac will only get be
>> MacPorts 1.8.0
>>
>> --
>> Ticket URL: <http://trac.macports.org/ticket/22423>
>> MacPorts <http://www.macports.org/>
>> Ports system for Mac OS
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
--
Thomas de Grivel
http://b.lowh.net/billitch/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
ecently to git for a few of my
own projects and am very pleased. It is much faster and helps commits
to be really atomic, both because it's not reliant on network. Also
backing up / providing a git tree is really easy, as simple as copying
a directory. Even server-side I am glad to progress
close them in less than a year.. ; )
Cheers,
--
Thomas de Grivel
http://b.lowh.net/billitch/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
rom the original proposition by Ryan. It just came to my mind that
variants could be suggested as well in a very useful way.
--
Thomas de Grivel
http://b.lowh.net/billitch/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosf
2009/2/9 Ryan Schmidt :
>
> On Feb 8, 2009, at 21:24, Thomas de Grivel wrote:
>
>> just thinking out loud :
>> maybe we could suggest variants as well ?
>
> I would say no to this suggestion, because a port should already come
> pre-configured for the recommende
atives-append port:graphviz-gui
> }
>
> (I used "suggest" instead of "recommend" in the keyword names because people
> have more trouble spelling "recommend".)
just thinking out loud :
maybe we could suggest variants as well ?
and propose building (or even rebuil
://trac.lowh.net/billitch/browser/mp-revdep-rebuild/mp-revdep-rebuild
please tell me about bugs ;)
--
Thomas de Grivel
http://b.lowh.net/billitch/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi
2008/2/7, Ryan Schmidt <[EMAIL PROTECTED]>:
>
> On Feb 7, 2008, at 09:10, Vincent Lefevre wrote:
>
> > On 2008-02-07 15:21:41 +0100, Thomas de Grivel wrote:
> >
> >> 2008/2/7, Ryan Schmidt:
> >>
> >>> It was proposed that -devel ports sho
ggest to rip it off them but that is another existing solution to
this problem. Well multiple versions is another larger issue I don't
mean to bring here.
--
Thomas de Grivel
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
2008/2/5, js <[EMAIL PROTECTED]>:
> On Feb 5, 2008 9:57 PM, Thomas de Grivel <[EMAIL PROTECTED]> wrote:
> > 2008/2/4, Vincent Lefevre <[EMAIL PROTECTED]>:
> > > On 2008-02-04 11:27:24 -0600, Ryan Schmidt wrote:
> > > > Regarding the sugges
we would have to warn new users about -latest not being so stable
because intuitively I would like the latest version to be installed
but what retains me the the previous one is that "it just works". For
the sake of stability I would have -unstable marked clearly, so that
the users dont expect too much magic with -latest.
--
Thomas de Grivel
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
variant:
> port install-> @... (nothing evaluated)
> port install +baz -> @... (nothing evaluated)
> port install -baz -> @...-baz (first block evaluated)
>
> > What if we add some new flag? I like the idea of variant -
> > some_variant, but maybe we could also add a default keyword which
> > says if this variant is going to be installed by default.
> >
> > Like this:
> > variant x11 description {Install X11 support} default {
> ># x11
> > } else {
> ># no x11
> > }
>
> Sure. The -variant syntax just sounds more intuitive to me, but one
> could say I'm strange.
>
> > I like the overall idea to simplify the default variants handling!
I like it. If there is some kind of poll here, I'm in =)
--
Thomas de Grivel
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
t in a
modern website you ought to separate infrastructure and content,
because both always change and could always be further improved (and
will be hopefully). However if you wait one to be finished to start
the other you will cripple yourself badly because none of them will
ever be finished.
I assume some translated copy of the site could be made available
rather simply and when the time comes it could be merged into the new
optimized infrastructure. Well.. that's just suggestion as I can't do
much more right now (I might contribute to some ports soon enough
though ; ) .
Hope it helps, regards,
--
Thomas de Grivel
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
20 matches
Mail list logo
