39 replies to this topic

[pscEx]

The current (still unpublished) version RC3 will have a slightly changed log.html:

maybe on the first view you do not see anything interesting.
But concentrate onto the parenthesis behind the version numbers.
There is () or (?) or (+).

This is the result of a new functionality:

Let me explain a bit history. When trying to help with issues, last time it sometimes happened that the user changed a script (and did not tell us!) which then became erroneous. To find that in the log, is a hard job, and in many cases unsuccessful.

That brought me to the idea:

When a project 'owner' uploads a script, he gives a 'stamp' to the script which is unique. Every change of the script can be detected.

Of course, 'changeable' data like interface values, are not included into the stamp.

So, in the log it is easy to be seen when the script has been changed in core areas.

• () > script does not have the stamp
• (+) > script is still original
• (?) > script has been changed.

How to apply:
As understandable, this is a tool exclusive for 'project-owners' to certify their scripts.
I wrote a small console program to 'certify' the script before upload.
It writes something like

Certification=4f912b81727e8e7d8869ac2c1cc8bf83

into the [Main] section of the script.
To avoid hacking: This is not MD5

To get it, please PM me.

Peter

[olegpov]

As understandable, this is a tool exclusive for 'project-owners' to certify their scripts.
I wrote a small console program to 'certify' the script before upload.

Peter why it not include in new WB ?

[pscEx]

Peter why it not include in new WB ?

To write the 'certification' should be possible for 'project owners' only.
If it is included in WB, everybody could do and the functionality looses it's reason.

The check for integrity is, as explained, in new WB.

Peter

[Lancelot]

pm on the way

[Galapo]

Hi Peter,

I was going to email you about obtaining the program, but Lancelot was a bad boy and supplied me with already.

Of course, 'changeable' data like interface values, are not included into the stamp.

Not sure exactly what you mean here. I discovered in my tests that if a user supplies input to interface, eg selecting a different radio button etc., that the certification does not then match. I would have that that certification should still match in this case. That is, what we're after is a way to tell if a user modifies as script, say adding additional radio buttons, or adding extra process lines etc.

Regards,
Galapo.

[Lancelot]

Hi Galapo,

I am confused, I re-test with changing interfaces of some scripts (radio buttons, checkboxes) and get same certification.
Maybe you mean sth different,
Adding new checkbox to interface keeps same certification, but this does not mean anything since nothing on process changed.
Maybe adding a button to make a existant section process but this wont have effect on building.

For now I cant imagine a situation to break current mechanism, Can you give example with a script causing different certification ?

[Galapo]

Hi Lancelot,

Take this script as an example.

Certifying it as it comes off the server I get:

Certification=405bf8facbcb971197681a0fdbce20f2

In WB, I enable the script and then change pScrollBox1 to %SettingsDrive%. I then get an entirely different certification:

Certification=888ba9a4f3e2c2e50f6b20f24720cc5c

Regards,
Galapo.

[Lancelot]

Hi Galapo

Just found, using "indent" with winbuilder editor causing this , not the selection.

I am pretty familiar with this from the first day indent introduced which also cause different md5 checksums if indent used/unused . I hope peter find a workaround for certification.

[Galapo]

So the issue lies in certifying an indented script. I guess certify.exe should standardise the way it certifies: either indent (if not already indented) or unindent (if not already) before carrying out the certification stamp. Then I guess WB also would require an update too (bring on 079 beta 1!).

Regards,
Galapo.

[pscEx]

Thanks, Galapo and Lancelot!

I have to confess that I did not think about the indent.

I'll change it, but unfortunatelly like Galapo says, publishing has to wait until 079 beta 1.

Peter

[Galapo]

Thanks, Peter! No rest for the wicked, hey. Already we await a new beta!

Regards,
Galapo.

[Lancelot]

Already we await a new beta!

Die unendliche Geschichte (The Neverending Story (novel)) , Well I even like waiting new betas/nightly builds/rc, I like to see the improvements all the time, and dont forget the fun, "what will be name of next version" is a common question till new version released. (bets to table )

Besides jokes, Thanks Peter for the hard work on development.


As a result I guess better to stop certifications of scripts till new wb/certification is published !

[pscEx]

I'm not sure whether to stop.

There are two types of users:

The 'Standard' user will modify only options in the interface. For him the certification will remain as calculated during upload.
The 'Curious' user will look into the source and perhaps distroy the certification. That is the sence of it, to detect modifications.

Next version will be enhanced and show only logical modifications. Indenting is no logical modification.

Peter

[Lancelot]

I'm not sure whether to stop.

What you suggest, should we continue certification without indent ?

A request idea came to me after this topic, and I wrote to bug tracker request section here, 2nd goal will be fixed with new certification (written by psc with assuming indent unlogical), but still I feel a good request for 1st and 3rd goals. (maybe not...)

[pscEx]

To calculate certification with fixed either 'With Indent' or 'Without Indent' would demand a big administrative work with the really easy possibility to make a mistake.

So I think: Let it for now like it is. We know that the certification is not yet optimized, but it works somehow.

Bugtracker is not thought for discussions. Therefore what you guessed there, is not really correct.

Therefore I continue here (And I think that this topic is the right place).

MD5 is already used for binary files like tools.

To use it for scripts is not possible because the MD5 varies depending on interface user options, selection etc.

(And now, why here is the right place)

That is the reason I 'invented' the certification.
Why not use the certification for download decision?

Peter

BTW: If in the future somebody is looking around some waste paper boxes, thrash etc. he / she will find a (+) in the certification column independent from indent.

WB will calculate both (with and without indent) values and check whether one of them is correct.
But that is really thrash. For a final version it is too time consuming.

[pscEx]

and dont forget the fun, "what will be name of next version" is a common question till new version released. (bets to table )

078 SP1 is still unused
Peter

[Lancelot]

psc

Request MAINLY aiming projects with multi admins on server maintance, as written main goal has nothing to do with certification but only a temporary way.

I already know the usage/ideas of bugtracker,md5,certification....

thanks for "Status Confirmed", If we have such feature with next wb life will be easier for multi admins.

Why not use the certification for download decision?

With new version of certification, a script can have same cert. number but different md5.

It will be nice to have both options available (due to certification, due to md5).
I would use "due to md5" for server maintance and Will ask new users to download "due to certification" when there is certification mismatch .

I hope it is the end of the successfull brain storm .

ps: Himm, maybe we can be more creative on winbuilder name , "Winbuilder 078 Shorttale" (reminding longhorn )

[was_jaclaz]

I hope it is the end of the successfull brain storm .

If this is a brain storm, I guess I can chime in to say "I completely disagree on the model".

If this is intended as a "security" measure of some kind, uncontrolled distribution is not advised.

I mean, as it has happened, that Lancelot (bad, bad boy ) bypassed the central distribution point it is very probable that this will happen again.

Which may result in due time in the certification app being available even to people that should not have it.

The obvious way out would be that psc creates a privete/public key mechanism and each "trusted" .script developer receives his/her own "signed" copy of the utility, so that from the actual verification code one could also identify the actual .script developer. (and if anyone is using someone else's utility).

Let me think...

... I seem to remember a similar mechanism, with a centralized "certification" ....

... here it is :

Bill's way





jaclaz

[pscEx]

Jaclaz, you think similar than me!

This is where I'm just working on:

Peter

[Lancelot]

Ehm,,, with being a very very bad boy I have some scenerio that would result same script, with certification (+), with same script version but with different certification author. With having new value on main section I guess it is better to see the name of the certifier on log to clear future misunderstanding(s)

Weather is stormy today

[Galapo]

Maybe Peter will have to go down the lines of other software having product activation...!

[pscEx]

Maybe Peter will have to go down the lines of other software having product activation...!

Do you want to help me with this?

Peter

[pscEx]

@all: stay on the ground.

Certification was thought as a quick&dirty check whether the script has been changed.

The reason was not to create a '1984 BigBrother watching you' system. The reason was to help helpers finding an issue in the log.

We all should remember this.

Peter

[Galapo]

Do you want to help me with this?

No thank you.

I should have refused the warez...

[pscEx]

With having new value on main section I guess it is better to see the name of the certifier on log to clear future misunderstanding(s)

Done

Peter

[079 beta 1]
date=2009-09-02

fixed - source indenting disturbed certification
fixed - CopyOrExpand of single *.ca_ file does not work
fixed - leading and trailing spaces in variables were lost.
fixed - download issues when proxy does not allow DNS
fixed - Bug ID #211: Access violation
changed - certification issuer shown in log, when applicable