Smalltalk › Squeak › Squeak - Dev

Re: [Vm-dev] VM Maker: VMMaker-oscog.52.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

19 messages Options

Eliot Miranda-2

Re: [Vm-dev] VM Maker: VMMaker-oscog.52.mcz

On Sun, Mar 20, 2011 at 11:23 AM, Tobias Pape <[hidden email]> wrote:

Am 2011-03-20 um 19:17 schrieb Eliot Miranda:

>
>
> On Sun, Mar 20, 2011 at 11:15 AM, Tobias Pape <[hidden email]> wrote:
>
> Am 2011-03-20 um 19:09 schrieb Eliot Miranda:
>
> > -------
> > Name: VMMaker-oscog.52
> > Author: IgorStasenko
> > Time: 18 March 2011, 12:45:14 am
> > UUID: a2810aac-4423-6740-b70e-7e821b979cb4
> > Ancestors: VMMaker-oscog-IgorStasenko.50,
> > VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51
> >
> > Merge with oscog-49-51 & Esteban-50
> > -------
> >
> > I feel like you continuously ignoring my requests to merge the code
> > base.. and work together on merged instance
> > of VMMaker.
> > If you don't like this code, just say it. But don't ignore.
> >
> > Its not intentional. It's simply a matter of finding time to do the merge. Mariano posted a bug. I fixed just that bug and published. I'm not dissing you. I have very limited time.
> >
>
> Hmm, wouldn't applying the “default” naming scheme prevent such overwrites?
>
> That is, now there would be
> VMMaker-oscog-eem.52
> for Elliots version and
> VMMaker-oscog-IgorStasenko.52
> for Igors version.
> What would prevent us from that?
>
> I don't see a naming conflict. I've been using VMMaker-oscog.NN since the beginning and Igor has been using VMMaker-oscog-IgorStasenko.NN. This isn't about names, it's about content. Igor is miffed I didn't merge in some changes he made when I published VMMaker-oscog.52, right Igor?
>

No, you—obviously accidentally—overwrote his version of the 18th of March:

So how did Monticello allow me to do that? That's a /bad/ bug.

>>>
Name: VMMaker-oscog.52
Author: IgorStasenko
Time: 18 March 2011, 12:45:14 am
UUID: a2810aac-4423-6740-b70e-7e821b979cb4
Ancestors: VMMaker-oscog-IgorStasenko.50, VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51

Merge with oscog-49-51 & Esteban-50
<<<<

which has the same file name as yours:

>>>
Name: VMMaker-oscog.52

Author: eem
Time: 20 March 2011, 9:31:20 am
UUID: 1241a856-8570-4725-a069-a6d3d8a8a222
Ancestors: VMMaker-oscog.51

Fix primitiveFlushCacheByMethod for objects-as-methods.
<<<<

Since oscog is, as far as I can see, a kind-of branch of the
“default” VM-Maker, I think adding the developer initial/name to
the Package name would be in the spirit of monticello idioms.

Except that its my branch and I've been using oscog from the start. Igor had no need to use the same name line as me. I don't want to change now. oscog refers to my branch of VMMaker for "open source Cog".

cheers

Eliot

So Long,
-Tobias

Tapple Gao

Re: [Vm-dev] VM Maker: VMMaker-oscog.52.mcz

On Sun, Mar 20, 2011 at 11:26:20AM -0700, Eliot Miranda wrote:
> Except that its my branch and I've been using oscog from the start. Igor
> had no need to use the same name line as me. I don't want to change now.
> oscog refers to my branch of VMMaker for "open source Cog".

It's not really open source if nobody else can contribute to
that branch. Squeaksource apparently allows versions to be
overwritten. I didn't know that either. Maybe that's part of the
reason the naming convention has been adopted:
Package-author.version

The best supported convention for maintaining a branch is to use
a different repository. MC is distributed, so packages can be
merged between repositories no problem.

So http://squeaksource.com/VMMaker/VMMaker-IgorStasenko.53.mcz
would be a trunk commit, and
http://squeaksource.com/OSCog/VMMaker-IgorStasenko.54.mcz would
be a cog commit.

Changing the package name is not really supported; Most MC
implementations can't merge between packages (MC1.5 could, but I
havn't ported that to any MC that's actually in use)

I like seperate repositories better anyway; then you can know if
there is a newer version of your branch available just by seeing
if VMMaker package is bold in the repo browser; if they are in
the same repository, you have to pay attention to the commits

--
Matthew Fulmer (a.k.a. Tapple)

Igor Stasenko

Re: [Vm-dev] VM Maker: VMMaker-oscog.52.mcz

On 20 March 2011 20:33, Matthew Fulmer <[hidden email]> wrote:

>
> On Sun, Mar 20, 2011 at 11:26:20AM -0700, Eliot Miranda wrote:
>> Except that its my branch and I've been using oscog from the start. Igor
>> had no need to use the same name line as me. I don't want to change now.
>> oscog refers to my branch of VMMaker for "open source Cog".
>
> It's not really open source if nobody else can contribute to
> that branch. Squeaksource apparently allows versions to be
> overwritten. I didn't know that either. Maybe that's part of the
> reason the naming convention has been adopted:
> Package-author.version
>
> The best supported convention for maintaining a branch is to use
> a different repository. MC is distributed, so packages can be
> merged between repositories no problem.
>
> So http://squeaksource.com/VMMaker/VMMaker-IgorStasenko.53.mcz
> would be a trunk commit, and
> http://squeaksource.com/OSCog/VMMaker-IgorStasenko.54.mcz would
> be a cog commit.
>
> Changing the package name is not really supported; Most MC
> implementations can't merge between packages (MC1.5 could, but I
> havn't ported that to any MC that's actually in use)
>
> I like seperate repositories better anyway; then you can know if
> there is a newer version of your branch available just by seeing
> if VMMaker package is bold in the repo browser; if they are in
> the same repository, you have to pay attention to the commits
>

I agree that having different repos could simplify things.
Except things which will otherwise complicate them:
- publishing new VMMaker version sends nice email to mailing list
- configuration(s) to automatically load VMMaker with all
dependencies relying on having VMMaker package at certain known
location,
not at multiple ones.

So, lets keep pushing to SqS/VMMaker but use different naming scheme.

> --
> Matthew Fulmer (a.k.a. Tapple)
>

--
Best regards,
Igor Stasenko AKA sig.

Tapple Gao

Re: [Vm-dev] VM Maker: VMMaker-oscog.52.mcz

On Sun, Mar 20, 2011 at 10:02:05PM +0100, Igor Stasenko wrote:
> I agree that having different repos could simplify things.
> Except things which will otherwise complicate them:
> - publishing new VMMaker version sends nice email to mailing list

This is just a setting in SqueakSource that can be set for any
repository. Just have both repositories notify this list

> - configuration(s) to automatically load VMMaker with all
> dependencies relying on having VMMaker package at certain known
> location,
> not at multiple ones.

If you want to load a working VMMaker, you aren't going to mix
stuff from cog and stable VMMaker repositories without a manual
merge first. And if you are talking about .mcm files, they
support multiple repositories, as long as package names are not
duplicated (like, if there are two different packages named
VMMaker-oscog.52 in each repo, it's undefined which one mcm will
load)

--
Matthew Fulmer (a.k.a. Tapple)

Igor Stasenko

Re: [Vm-dev] VM Maker: VMMaker-oscog.52.mcz

On 21 March 2011 02:16, Matthew Fulmer <[hidden email]> wrote:

> On Sun, Mar 20, 2011 at 10:02:05PM +0100, Igor Stasenko wrote:
>> I agree that having different repos could simplify things.
>> Except things which will otherwise complicate them:
>> - publishing new VMMaker version sends nice email to mailing list
>
> This is just a setting in SqueakSource that can be set for any
> repository. Just have both repositories notify this list
>
>> - configuration(s) to automatically load VMMaker with all
>> dependencies relying on having VMMaker package at certain known
>> location,
>> not at multiple ones.
>
> If you want to load a working VMMaker, you aren't going to mix
> stuff from cog and stable VMMaker repositories without a manual
> merge first. And if you are talking about .mcm files, they
> support multiple repositories, as long as package names are not
> duplicated (like, if there are two different packages named
> VMMaker-oscog.52 in each repo, it's undefined which one mcm will
> load)
>

No i'm talking about Metacello configuration, which currently used to
load VMMaker.
But you are right, i still manually control each update, so i can
always change the location & packages which should be loaded
for new version(s).

> --
> Matthew Fulmer (a.k.a. Tapple)
>
>

--
Best regards,
Igor Stasenko AKA sig.

Levente Uzonyi-2

Re: [Vm-dev] VM Maker: VMMaker-oscog.52.mcz

In reply to this post by Tapple Gao

On Sun, 20 Mar 2011, Matthew Fulmer wrote:

>
> On Sun, Mar 20, 2011 at 11:26:20AM -0700, Eliot Miranda wrote:
>> Except that its my branch and I've been using oscog from the start. Igor
>> had no need to use the same name line as me. I don't want to change now.
>> oscog refers to my branch of VMMaker for "open source Cog".
>
> It's not really open source if nobody else can contribute to
> that branch. Squeaksource apparently allows versions to be

Open source ~= open repository. (It's funny that squeaksource.com has lots
of repositories with MIT license and "No access" setting.)

> overwritten. I didn't know that either. Maybe that's part of the
> reason the naming convention has been adopted:
> Package-author.version
>
> The best supported convention for maintaining a branch is to use
> a different repository. MC is distributed, so packages can be
> merged between repositories no problem.

If the idea is to merge the two branches, then it's unnecessary.

>
> So http://squeaksource.com/VMMaker/VMMaker-IgorStasenko.53.mcz
> would be a trunk commit, and
> http://squeaksource.com/OSCog/VMMaker-IgorStasenko.54.mcz would
> be a cog commit.
>
> Changing the package name is not really supported; Most MC
> implementations can't merge between packages (MC1.5 could, but I

Yeah, that's pretty annoying.

> havn't ported that to any MC that's actually in use)
>
> I like seperate repositories better anyway; then you can know if
> there is a newer version of your branch available just by seeing
> if VMMaker package is bold in the repo browser; if they are in
> the same repository, you have to pay attention to the commits

If you save directly to the repository, then MC will warn you if there's
a newer version there, if you copy your package from another repository,
then it won't.

Levente

>
> --
> Matthew Fulmer (a.k.a. Tapple)
>

Tapple Gao

Security Vunerability in SqueakSource

In reply to this post by Eliot Miranda-2

Marcus Denker-4

Re: [Pharo-project] Security Vunerability in SqueakSource

In reply to this post by Eliot Miranda-2

On Mar 21, 2011, at 3:24 AM, Matthew Fulmer wrote:

> As demonstrated by the VMMaker team, SqueakSource has a rather
> serious security vunerability:
>

Serious security problems are normally send to the admins of
a website first (so they fix it) instead of sending it to a mailinglist...

Marcus

--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Tobias Pape

Re: Security Vunerability in SqueakSource

In reply to this post by Tapple Gao

Am 2011-03-21 um 03:24 schrieb Matthew Fulmer:

> As demonstrated by the VMMaker team, SqueakSource has a rather
> serious security vunerability:
>
> http://bugs.squeak.org/view.php?id=7617
>
> Below is the dialog that led to this discovery:
>

Note that SqueakSource 2 and 3 are unaffected of this bug.
Moreover, find attached a quick fix that is a backport of
the conflict handling in SqueakSource 2 to the original
SqueakSource.

HTH

So Long,
-Tobias

FixSqueakSource.1.cs (3K) Download Attachment

Marcus Denker-4

Re: [Pharo-project] [squeak-dev] Security Vunerability in SqueakSource

In reply to this post by Tapple Gao

On Mar 21, 2011, at 9:27 AM, Tobias Pape wrote:

> Am 2011-03-21 um 03:24 schrieb Matthew Fulmer:
>
>> As demonstrated by the VMMaker team, SqueakSource has a rather
>> serious security vunerability:
>>
>> http://bugs.squeak.org/view.php?id=7617
>>
>> Below is the dialog that led to this discovery:
>>
>
>
> Note that SqueakSource 2 and 3 are unaffected of this bug.
> Moreover, find attached a quick fix that is a backport of
> the conflict handling in SqueakSource 2 to the original
> SqueakSource.
>

Ok, we added the fix.

We verified and versions are not overridden.

The strange thing is that MC in the image thinks it was successful and gets confused.
A restart of the image shows the correcnt data, so on the squeaksource side the
meta data is ok.

So as a first workaround, this is working but we should look into a correct error handling
on the MC on the image side later.

Marcus

--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Bert Freudenberg

Re: Security Vunerability in SqueakSource

In reply to this post by Tapple Gao

It's surprising to me that you find this "news".

SqueakSource is simply a WebDAV server. All the versioning logic is local, implemented in Monticello, so allowing overwrites is not really SqueakSource's "fault". Besides, even if SqueakSource disallowed overwriting a version (which it probably should) nothing would prevent somebody else to upload a *new* version that did something bad.

Loading Squeak code is inherently dangerous. Installing code usually executes "initialize" methods immediately. That could easily wipe your disk, since almost nobody is using the VM's sandbox (AFAIK, only Etoys uses that feature). OTOH this is not much different from installing a Linux package which also executes "install scripts" that potentially could do a lot of danger. But e.g. the trunk repository is not world-writable so there is no immediate risk.

It would be a lot safer if we had signed MCZ packages. Or even better, a tamper-proof history (like git).

- Bert -

On 21.03.2011, at 03:24, Matthew Fulmer wrote:

> As demonstrated by the VMMaker team, SqueakSource has a rather
> serious security vunerability:
>
> http://bugs.squeak.org/view.php?id=7617
>
> Below is the dialog that led to this discovery:
>
>
> On Sun, Mar 20, 2011 at 11:26:20AM -0700, Eliot Miranda wrote:
>>>> Hmm, wouldn't applying the “default” naming scheme prevent such
>>> overwrites?
>>>>
>>>> That is, now there would be
>>>> VMMaker-oscog-eem.52
>>>> for Elliots version and
>>>> VMMaker-oscog-IgorStasenko.52
>>>> for Igors version.
>>>> What would prevent us from that?
>>>>
>>>> I don't see a naming conflict. I've been using VMMaker-oscog.NN since
>>> the beginning and Igor has been using VMMaker-oscog-IgorStasenko.NN. This
>>> isn't about names, it's about content. Igor is miffed I didn't merge in
>>> some changes he made when I published VMMaker-oscog.52, right Igor?
>>>>
>>>
>>> No, you—obviously accidentally—overwrote his version of the 18th of March:
>>>
>>
>> So how did Monticello allow me to do that? That's a /bad/ bug.
>>
>>
>>>
>>>>>>
>>> Name: VMMaker-oscog.52
>>> Author: IgorStasenko
>>> Time: 18 March 2011, 12:45:14 am
>>> UUID: a2810aac-4423-6740-b70e-7e821b979cb4
>>> Ancestors: VMMaker-oscog-IgorStasenko.50,
>>> VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51
>>>
>>> Merge with oscog-49-51 & Esteban-50
>>> <<<<
>>>
>>> which has the same file name as yours:
>>>
>>>>>>
>>> Name: VMMaker-oscog.52
>>> Author: eem
>>> Time: 20 March 2011, 9:31:20 am
>>> UUID: 1241a856-8570-4725-a069-a6d3d8a8a222
>>> Ancestors: VMMaker-oscog.51
>>>
>>> Fix primitiveFlushCacheByMethod for objects-as-methods.
>>> <<<<
>
> --
> Matthew Fulmer (a.k.a. Tapple)
>

Sven Van Caekenberghe

Re: Security Vunerability in SqueakSource

On 21 Mar 2011, at 11:20, Bert Freudenberg wrote:

> SqueakSource is simply a WebDAV server. All the versioning logic is local, implemented in Monticello, so allowing overwrites is not really SqueakSource's "fault". Besides, even if SqueakSource disallowed overwriting a version (which it probably should) nothing would prevent somebody else to upload a *new* version that did something bad.

Yes versioning/naming is local and distributed, that is a feature. One cannot rely on the name alone.
However, it is most certainly a bug that a server happily overwrites existing versions, a version control system should never do that.

Your other points a valid, of course.

Sven

Marcus Denker-4

Re: [Pharo-project] [squeak-dev] Security Vunerability in SqueakSource

In reply to this post by Bert Freudenberg

On Mar 21, 2011, at 12:23 PM, Sven Van Caekenberghe wrote:

>
> On 21 Mar 2011, at 11:20, Bert Freudenberg wrote:
>
>> SqueakSource is simply a WebDAV server. All the versioning logic is local, implemented in Monticello, so allowing overwrites is not really SqueakSource's "fault". Besides, even if SqueakSource disallowed overwriting a version (which it probably should) nothing would prevent somebody else to upload a *new* version that did something bad.
>
> Yes versioning/naming is local and distributed, that is a feature. One cannot rely on the name alone.
> However, it is most certainly a bug that a server happily overwrites existing versions, a version control system should never do that.
>
> Your other points a valid, of course.
>
>

I think that "security" was not meant in the sense of accidentally loading wrong code. More in the sense that one could just
delete all your code. Even though we have backups of the SqueakSource filesystem, you don't want that, as it would be a
mess to repair.

Marcus

--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Bert Freudenberg

Re: [Pharo-project] [squeak-dev] Security Vunerability in SqueakSource

On 21.03.2011, at 12:40, Marcus Denker wrote:

>
> On Mar 21, 2011, at 12:23 PM, Sven Van Caekenberghe wrote:
>
>>
>> On 21 Mar 2011, at 11:20, Bert Freudenberg wrote:
>>
>>> SqueakSource is simply a WebDAV server. All the versioning logic is local, implemented in Monticello, so allowing overwrites is not really SqueakSource's "fault". Besides, even if SqueakSource disallowed overwriting a version (which it probably should) nothing would prevent somebody else to upload a *new* version that did something bad.
>>
>> Yes versioning/naming is local and distributed, that is a feature. One cannot rely on the name alone.
>> However, it is most certainly a bug that a server happily overwrites existing versions, a version control system should never do that.
>>
>> Your other points a valid, of course.
>>
>>
> I think that "security" was not meant in the sense of accidentally loading wrong code. More in the sense that one could just
> delete all your code. Even though we have backups of the SqueakSource filesystem, you don't want that, as it would be a
> mess to repair.
>
> Marcus

IIRC SqueakSource keeps the old version as a separate file when "overwriting", so nothing is really lost. It's cumbersome to restore though indeed.

- Bert -

NorbertHartl

Re: [Pharo-project] [Vm-dev] VM Maker: VMMaker-oscog.52.mcz

In reply to this post by Tapple Gao

Just for the record. If anyone is having his own monticello repository like me using apache a rule

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^PUT
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule . - [F,L]

will prevent overwriting of packages. The full story is at

http://norbert.hartl.name/blog/public-monticello-repository

Norbert

Igor Stasenko

Re: [Pharo-project] [squeak-dev] Security Vunerability in SqueakSource

In reply to this post by Bert Freudenberg

On 21 March 2011 12:54, Bert Freudenberg <[hidden email]> wrote:

>
> On 21.03.2011, at 12:40, Marcus Denker wrote:
>
>>
>> On Mar 21, 2011, at 12:23 PM, Sven Van Caekenberghe wrote:
>>
>>>
>>> On 21 Mar 2011, at 11:20, Bert Freudenberg wrote:
>>>
>>>> SqueakSource is simply a WebDAV server. All the versioning logic is local, implemented in Monticello, so allowing overwrites is not really SqueakSource's "fault". Besides, even if SqueakSource disallowed overwriting a version (which it probably should) nothing would prevent somebody else to upload a *new* version that did something bad.
>>>
>>> Yes versioning/naming is local and distributed, that is a feature. One cannot rely on the name alone.
>>> However, it is most certainly a bug that a server happily overwrites existing versions, a version control system should never do that.
>>>
>>> Your other points a valid, of course.
>>>
>>>
>> I think that "security" was not meant in the sense of accidentally loading wrong code. More in the sense that one could just
>> delete all your code. Even though we have backups of the SqueakSource filesystem, you don't want that, as it would be a
>> mess to repair.
>>
>> Marcus
>
>
> IIRC SqueakSource keeps the old version as a separate file when "overwriting", so nothing is really lost. It's cumbersome to restore though indeed.
>

yeah, we saw that mechanism there. But have no idea where it storing backups :)

> - Bert -
>
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Bert Freudenberg

Re: [Pharo-project] [squeak-dev] Security Vunerability in SqueakSource

On 21.03.2011, at 16:57, Igor Stasenko wrote:

> On 21 March 2011 12:54, Bert Freudenberg <[hidden email]> wrote:
>>
>> On 21.03.2011, at 12:40, Marcus Denker wrote:
>>
>>>
>>> On Mar 21, 2011, at 12:23 PM, Sven Van Caekenberghe wrote:
>>>
>>>>
>>>> On 21 Mar 2011, at 11:20, Bert Freudenberg wrote:
>>>>
>>>>> SqueakSource is simply a WebDAV server. All the versioning logic is local, implemented in Monticello, so allowing overwrites is not really SqueakSource's "fault". Besides, even if SqueakSource disallowed overwriting a version (which it probably should) nothing would prevent somebody else to upload a *new* version that did something bad.
>>>>
>>>> Yes versioning/naming is local and distributed, that is a feature. One cannot rely on the name alone.
>>>> However, it is most certainly a bug that a server happily overwrites existing versions, a version control system should never do that.
>>>>
>>>> Your other points a valid, of course.
>>>>
>>>>
>>> I think that "security" was not meant in the sense of accidentally loading wrong code. More in the sense that one could just
>>> delete all your code. Even though we have backups of the SqueakSource filesystem, you don't want that, as it would be a
>>> mess to repair.
>>>
>>> Marcus
>>
>>
>> IIRC SqueakSource keeps the old version as a separate file when "overwriting", so nothing is really lost. It's cumbersome to restore though indeed.
>>
>
> yeah, we saw that mechanism there. But have no idea where it storing backups :)

I'd have to look at the code but I think it just renames the old file, appending a numeric suffix.

- Bert -

Tobias Pape

Re: [Pharo-project] [squeak-dev] Security Vunerability in SqueakSource

Am 2011-03-21 um 17:23 schrieb Bert Freudenberg:

>
> On 21.03.2011, at 16:57, Igor Stasenko wrote:
>
>> On 21 March 2011 12:54, Bert Freudenberg <[hidden email]> wrote:
>>>
>>> On 21.03.2011, at 12:40, Marcus Denker wrote:
>>>
>>>
>>>
>>> IIRC SqueakSource keeps the old version as a separate file when "overwriting", so nothing is really lost. It's cumbersome to restore though indeed.
>>>
>>
>> yeah, we saw that mechanism there. But have no idea where it storing backups :)
>
> I'd have to look at the code but I think it just renames the old file, appending a numeric suffix.
>
> - Bert -
>
>
>

It appends the date:

backupExtensionFor: aString
| timestamp |
timestamp := TimeStamp current.
^String streamContents: [ :stream |
timestamp date printOn: stream format: #(3 2 1 $- 1 1 2).
stream nextPut: $..
stream nextPutAll: (timestamp time print24 collect: [ :each |
each isDigit ifTrue: [ each ] ifFalse: [ $- ] ]) ].

So Long,
-Tobias

Tapple Gao

Re: [Pharo-project] Security Vunerability in SqueakSource

In reply to this post by Marcus Denker-4

On Mon, Mar 21, 2011 at 09:15:03AM +0100, Marcus Denker wrote:
>
> On Mar 21, 2011, at 3:24 AM, Matthew Fulmer wrote:
>
> > As demonstrated by the VMMaker team, SqueakSource has a rather
> > serious security vunerability:
> >
>
> Serious security problems are normally send to the admins of
> a website first (so they fix it) instead of sending it to a mailinglist...

I have some idea who the squeaksource.com admins are, but not
the source.squeak.org admins. Also don't know who else has their
own squeaksource install

--
Matthew Fulmer (a.k.a. Tapple)