For now my extensions are going to be unsigned. I see no point in spending time reworking and moving files outside of my plugin folder. First of all this would cause many of my users grief. It would also make the installation more difficult as I would have 2 installers for each plugin.
Perhaps I’ll consider compressing all of editable text files that I supply. Then on startup I could then decompress them into various folders if they don’t already exist. That way the original compressed file wouldn’t change. At least this way I could keep it to a single install.
The best solution I can come up with is to create my own virtual store within my plugin folder. What I am contemplating is to have empty template folders within the store (I name the store folder ‘storage’).
My routines look for the template under storage so when looking for a rule I check first if it is in gkware_cabmaker\storage\rul and if not then look where it is for older versions which was gkware_camaker\rul
This strategy solves several potential issues:
It allows the signature to stay valid.
if users want to modify the supplied templates and they don’t or won’t rename the template then it won’t get overwritten during the next update.
And no Dan - I never said that you said …
And also no - I don’t have a question - I’m simply trying to share my observations.
I’ve apparently run into this problem also.
(My extensions are encrypted and signed automatically on their way to being tested by Trimble, who publishes them on the EW. Therefore, I never need to download the result. Which also means that I can’t easily test the result.)
In the last release of one of my extensions I added a one character txt file (either “y” or “n”) to record the user response this dialog which displays on initial load:
This reminder has eliminated countless support emails from customers too lazy to look at the help file after doing an update.
BUT it seems that my ruby code that writes “n” to the txt file invalidates the extension signature!!! Who knew?
None of the SU or SU API documentation mentions the “invalid signature” status or explains how it might occur and what its implications are for the “loading policy modes”.
I know I might have used the OS registry to do this, but wanted to avoid the untestable multiversion can of worms that this might entail.
Is there another file type other that txt that the signature process ignores?
Any other suggestions???
Sketchup.write_default('2DXY', 'SiteSurveyTools', reply)
# run on first run to set the default
if check_2dxy == nil
# in your dialog return code if changed by user
The Extension Warehouse could certainly be more transparent towards developers. A lot of problems seem to stem from this, e.g. the struggles I’ve had figuring out how licensing works.
However I’ve moved away from saving files in the extension directory. In some situations the user doesn’t even have write permission to this directory, e.g. when an extension is installed in the program folder to be shared between users.
I would use an approach similar to what John shows, but use Booleans rather than strings.
The official list of file-types which get hashed in the signing process is supposed to be…
RB [after encryption RBS/RBE], JS, CSS, HTM, HTML - because these can be changed and affect how an extension works.
The TXT file extension was originally excluded, but, for some [as yet unexplained], it’s now included in the signing process, so if your tool ships with a .TXT file it’s signed, and any changes to that file will break the validity of the signing.
At the moment file extensions like LOG, DAT, LIC etc seem to be ignored so you could try using one of those.
As explained above - Set/Get a setting using write_default/read_default is the simple way to save these values externally…
These set/get values are global and will apply to your tool when run in that SketchUp version, for any model.
If you want to set/get values on a model by model basis then set up a attribute attached directly to the model itself. This can then be accessed using get/set for each model, with defaults used if not already set up…
Your best [simplest] approach is probably not to ship [or at least sign] the RBZ with the TXT file in it, it can be created later and not affect the signing.
Of course the “powers that be” might make a decision to sign ALL files in the submitted RBZ and return an error should other files be found in that signed Extension’s subfolder !
Of course, this would be a major step, and would very likely disaffect many developers.
However, the initial, then ‘the enhanced’, signing process still arrived, despite considerable opposition from many developers [behind the scenes], and frankly it’s still without any real measurable benefit to users, or us developers !
Alternatively tell your users to set their Extension Loading Policy to be Unrestricted [at least for now]…
Just a note to say the “someone” was not aimed at you John. It was aimed at whomever had the “brilliant” idea to eval storage values in the first place.
Yes, but it would still be backwardly dangerous, … unless they patched old versions. (Which is unlikely to officially happen.)
It may be left for a third party patch to do.
I was just thinking about how to parse numeric strings (integers, floats, scientific notation, etc.) into the proper kind of Ruby numeric. Not much problem with some of the SketchUp API types as they call #inspect upon them before storage, ie: "Point3d(1.0,2.0,1.0)"
I’ve been thinking quite a lot about storing Lengths and other SU classes to JSON/file and parse it back to the original format again. I haven’t made any progress in that.
However I don’t think Point3ds and other advanced types are really needed in the registry, at least not for now. I almost only have stored Booleans and sometimes string identifiers for user settings using write_defaults. In the future it could perhaps be nice to have support for all SU types but to start with I think it’s most important to fix the security issue for newer SU versions.
Something similar to JSON.load could be used to read and #to_json could be used to write. Some special handling would be required when Ruby and JSON don’t match, e.g. nil vs null. I’m not sure if mayor versions can read and write to the same locations. If not there is no compatibility to maintain anyway.
When we say “registry” we now mean “storage” because most of extension storage has moved to JSON files, rather than the registry. (Native dialog sizes and positions are likely still in the registry.)
It would be nice to have parity between Attribute Dictionaries and JSON storage.
This means that the JSON library may need to be extended with a few API specific class generator methods. Not difficult because many have conversion methods to array and/or hash which are already JSON compatible.
The tricky part si to convert back to SketchUp classes. What in a JSON file could tell that a float is to be interpreted as a Length? Or an Array should be interpreted as a Vector3d? You’s have to extend the JSON specification along with rewriting a generator/parser to cater for these types.