I have signed my extension and it loads under the “Identified Extensions Only” policy when I put it in ‘C:\ProgramData\SketchUp\SketchUp 2016\SketchUp\Plugins’. However, when I put the same files in ‘C:\Users\dmacumbe\AppData\Roaming\SketchUp\SketchUp 2016\SketchUp\Plugins’ they are not seem as properly signed and won’t load under the “Identified Extensions Only” policy. The plugin will load from the user location in the “Unrestricted” mode. My understanding was that you could have signed extensions in the user location, is that right?
I am using SketchUp Make v 16.1.1449 64-bit.
When you say 'you have put them in…the Plugins folder’
Do you mean you have ‘installed’ them from a signed RBZ ?
The signed RBZ will include a loader RB and a subfolder of the same name including at least a .hash file and if it’s an extension some other support file[s]…
If properly signed they should appear in ALL policies…
I’m the developer of the OpenStudio extension. We create an RBZ for the signing step but then we extract the hash file and install our extension plus the hash file as part of our own installer. Our installer simply copies the files to ‘C:\ProgramData\SketchUp\SketchUp 2016\SketchUp\Plugins’ location, users don’t install an RBZ file. Does that make sense?
Previously, I could use our installer to put files in ‘C:\ProgramData\SketchUp\SketchUp 2016\SketchUp\Plugins’ for main releases but then put files in ‘C:\Users\dmacumbe\AppData\Roaming\SketchUp\SketchUp 2016\SketchUp\Plugins’ to test development versions. However, I found that SketchUp was not loading the plugin from ‘C:\Users\dmacumbe\AppData\Roaming\SketchUp\SketchUp 2016\SketchUp\Plugins’ when in the restricted mode, it was just falling back to using the one in ‘C:\ProgramData\SketchUp\SketchUp 2016\SketchUp\Plugins’.
The loading policy should list all available extensions - from both of those Plugins folders.
There are three policies.
Unrestricted loads all available ones, the signed-only highest setting ignores anything that’s not signed and the mid-level asks for approval of any unsigned ones…
If you have two extensions loading from the folders, but they have the exact same name [extension-name and/or loader .RB name], then the first one to load takes that name, and the second one is ignored as a duplicate.
$: to see the load order of those two Plugins folders - I suspect your ProgramData one is loading first ?
If you want to have a set up with two locations try disabling the one you are not working on at that moment by renaming its ‘loader’ .RB as .RB! and restarting SketchUp - then the one named .RB will be the only one found and loaded.
That is correct - that’s the main location for extensions in the first place. Are you seeing any error messages?
Thanks @thomthom1, I am not seeing any errors in the console, I just can’t click the extension in the preferences dialog.
Here are the configurations I tested:
"Identified Extensions Only" policy
- Plugin in user location, plugin does not load
- Plugin in program data location, plugin loads
- Plugin in user and program data, plugin does not load
- Plugin in user location, plugin loads
- Plugin in program data location, plugin loads
- Plugin in user and program data, plugin loads (not sure which location is used)
Here is the plugin, note that it will fail to load on your computer since you don’t have OpenStudio loaded. However, if it tries to load then that is good enough. Another thing to note, our installer writes a file ‘OpenStudio-config’ that loads the plugin from our other installed location. This file changes depending on where you install OpenStudio, we are counting on files with no extensions not being included in the plugin hash. Is that somehow different in user and program data locations?
OpenStudio.rbz (4.1 KB)
What about my earlier observation ?
Any loading Extension with the same name [+version], OR with a same name loader RB file using the same name, will not loaded.
The first one to be consider, and to load, will “claim” that name-slot, so any file in the second Plugins folder is simply ignored.
Try it yourself with some simple extension RB/subfolder/RB files…
Put them in both of those Plugins folders.
Obviously they need to be loading similarly named extensions, menu items etc…
If the the loader RB name or the Extension’s name +version are the exact match, then only the first to be considered will load.
In the Ruby Console
$: will show you the load order of the Plugins folders, so you should be able to deduce that the first loading one takes precedence…
Your use of:
is an unnecessary global variable - now frowned upon in newer scripts…
If you wrapped your code inside your own modules[s] from the start, then it could be a Constant within just that module:
A simpler usage [since it’s then encapsulated in the module] would be
Thanks @TIG, I understand about the load path. My question is why the same plugin, with the same files and same hash, will load from the Program Data location but not from the User location under the “Identified Extensions Only” policy?
@ChrisFullmer - can you have a look at this?
Maybe I am having a brain freeze…
But I am not following this…
If you have ONE version of your extension’s loader RB and its subfolder, and it has be properly signed, then it should load in the restricted policies, from either of the Plugins folders.
But if you place copies of it in both Plugins folders then only the one in the first loading ‘load-path’ folder will claim the extension name and block the second one loading.
I suspect that ProgramData’s Plugins is looked at first ?
Therefore it gets loaded instead of the alternative.
If you have edited any of the files [RB/RBS/RBE/HTM/HTML/JS/CSS] in the subfolder, e.g. to indicate which version is loading, then the hash will be broken for that one, thereby perhaps letting the other load instead.
OR are you saying that even with just one version of the properly signed files, in just one Plugins folder, the restricted policy does not let it load [ever] if it’s in the User’s AppData Plugins, but does load OK if it’s in the ProgramData’s equivalent folder ?
Yeah, maybe I did not explain it well enough but I am seeing the last behavior you mention @TIG.
Now I have done some tests of my own…
You are right in that in the restricted policy some extensions that are properly signed are not loading, some are.
For example on my system I have some of my own tools, and also some of thomthom’s tools, which I know to be both signed and the latest ones, but these do not load. But some others load just fine.
In the mid-range ‘approve’ policy I can select some files to load that are not signed and some that I know to be signed but are getting blocked - these then load OK, however some report as having expired or missing certificates ?
If I have the severest policy set, then extensions which are signed but not in the default Plugins folder [own custom folder added by Fredo’s Additional Plugins folder] do not get loaded.
If I then change to ‘approve’ policy and restart these extensions are not offered for approval in the list., but separate dialogs prompt for their approval, saying they have issues when they do not…
Frankly this whole issue of signing extensions introduced for v2016 has been badly thought out and mismanaged thus far [IMHO].
During v2016’s early days I have all but come to blows with some of the SketchUp staff.
It clearly doesn’t work as intended.
It is an onus on developers, not a blessing as has been portrayed.
It’s just another layer of annoyance that is neither needed nor wanted.
It offers no tangible benefit to developers and only an illusory comfort to users: if they get their RBZs from the EWH, SketchUcation or an established developer’s web-site - these are already a trusted source - but installing a signed RBZ from somewhere else is no real guarantee for its legitimacy or health - there is no vetting when signing, and the signing can be circumvented by devious individuals, whom we are told lurk out there to get us…
I have previously shown the SketchUp team [off-air] how a loading policy can be circumvented within a signed extensions: their response in hashing a whole raft of potential file-types in addition to RB, and also changing the load-order precedence for v2016 to RBE/RBS/RB [an improvement but still able to be fooled] was in some great part because of my comments.
So you are not wrong.
Signed extensions in the Plugins folder can generate a false response in the restricted loading-policies, whilst others load just fine, but it seems to have no pattern in this…
Anyone have a sample extension that display this behaviour?