Invalid Signature

Do you have a question ?

You seem not to understand that the package submitted for signing, is signed in the state it is when submitted.

Any later change to any of those files, will trigger an alert that an invalid change to one of the signed files has happened. It is the whole point of signing, after all.

So, if you need to be making changes to any configuration files at runtime, then they should not be included with the package when you submit it for signing.

My initial understanding was based on what Tig wrote in a Sketchucation post suggesting that txt files would be ignored. My testing showed that not to be quite correct.

http://sketchucation.com/forums/viewtopic.php?t=66202#p607908

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.

No. I did not say that. I said they should not be included when signing.

They can be written into the folder later. Or don’t use the “.txt” extension. or perhaps a sub-folder?

(Since they came out with this signing stuff, I’ve avoided doing anything with the EW. Waiting till the “kinks are ironed out.”)

What we seem to need is a “.ignore” file like Git uses.

Let me ping @ChrisFullmer, so you can get an answer “straight from the horse’s mouth.”

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:

  1. It allows the signature to stay valid.
  2. 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.

1 Like

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:
image
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???

def check_2dxy
  Sketchup.read_default('2DXY', 'SiteSurveyTools')
end

def write_2dxy(reply)
  Sketchup.write_default('2DXY', 'SiteSurveyTools', reply)
end

# run on first run to set the default
if check_2dxy == nil
  write_2dxy('y')
end

# in your dialog return code if changed by user
  write_2dxy('n')

should work for all versions since v6…

john

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.

anything gets converted to strings when using Sketchup.write_default, so you may as well use strings…

Sketchup.read_default will only return strings on a mac…

check your .json pref files to see if that’s the same on PC…

john

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]…

I tried to say that ~ a year ago …

:roll_eyes:

I hate SketchUp for Mac -_- . When using Windows there are no indications whatsoever that other types wouldn’t be supported.

I’ve tested on Windows (SU 2017). Booleans, Strings, Integers and Floats are supported. Symbols on the other hand seem to be executed when read o.0 .

Sketchup.write_default("test", "test", :symbol)
Sketchup.read_default("test", "test")
=> Error: #<NameError: undefined local variable or method `symbol' for main:Object>

Or

Sketchup.write_default("test", "test", :Sketchup)
Sketchup.read_default("test", "test").class
=> Class

This code perhaps be used for code injections

Sketchup.write_default("test", "test", :"Sketchup.active_model.entities.clear!")
Sketchup.read_default("test", "test") # Deletes all instances in the model root.

Now I’m getting tired.

YES! Finally someone gets it. I’ve been saying this for years.
In fact I said it here 2 days ago …

Everything read back is passed into eval() to reproduce the original object.

… and yes it was very unsafe ! Why else do you think they’ve switched to JSON parsed strings ?

Much much safer !

1 Like

JSON makes no difference, that code still deletes all entities when you call
Sketchup.read_default("test", "test")

it is stored without the symbol on mac…

        "test": {
            "test": "Sketchup.active_model.entities.clear!"
        },

john

It makes a difference if “someone” would not program such unsafe things.

I was just reading in the Chrome Extension tutorial how we should not eval JSON strings, … and should parse them instead.

Ruby has the same JSON.parse() method JavaScript has (except JS creates a JS Object, whereas Ruby creates a Hash object.)

ie … at SketchUp’s Ruby console …

json = '{ "test" : "Sketchup.active_model.entities.clear!" }'
hash = JSON.parse(json)
# model entities are STILL there !
hash.inspect
#=> {"test"=>"Sketchup.active_model.entities.clear!"}
1 Like

With a little luck it should be possible to refactor read_default to parse the registry entry properly, while still being backward compatible.

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.

For other readers it is trivial to store Ruby types in hashes and convert back and forth to and from JSON.

See example … (in another thread.)

Not a problem, see:

JSON::Ext::Generator::GeneratorMethods::NilClass

nil.to_json.inspect
#=> "null"

jstore = {:val => nil}.to_json
jstore.inspect
#=> "{\"val\":null}"

hash = JSON.parse(jstore,symbolize_names:true)
hash.inspect
#=> {:val=>nil}

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.

The need their own #to_json method defined so that they output “typed values” instead of #to_s by default. Similar to how the API #inspect overrides work …

Geom::Point3d.new(1,2,3).inspect.to_json
#=> "Point3d(1, 2, 3)"

Then JSON needs to know how to convert back using the class name, calling it’s constructor passing in the arguments.

The JSON library is designed to be expanded by adding class conversion definitions to the following directory:
"<rubylib>/json/lib/json/add"

You wouldn’t think ordinarily that Ruby Exception classes would be JSON compatible, but take a look at:
"<rubylib>/json/lib/json/add/exception.rb"

and you’ll get the idea quickly as there are only 3 methods to define.

1 Like