Extension Signing
-
On a related note I am testing my plugin within SU 2017 using the new Extension Manager. I notice that to get a logo to load from EW one needs to have extension_info.txt in your root folder. I understand where to get the extension ID from but how does one determine the VERSION_ID? If I just enter in the extension ID it does not work it appears to need the VERSION_ID in this file. However, the VERSION_ID is not given in the EW control panel or anywhere that I can see it.
-
You do not create nor edit the "extension_info.txt" file.
It is generated by the EW. When you get the signed RBZ package back, the file should have been inserted... and it goes in the extension sub-folder not in the root folder of the RBZ archive (which is actually the "Plugins" root folder.)
-
Your right it goes in the sub-folder not the root. However it would be really nice if I could just include this file with the appropriate ID and VERSION_ID since I have not set up my plugin to be downloaded through the Extension Warehouse. This file should only need to be hardcoded in just once and never change.
The only reason I would like this file to be present is so that my plugin/extension logo is properly displayed in the Extension Manager.
-
The extension_info is auto-generated by Extension Warehouse. You should not be modifying this yourself.
We have a feature request logged to allow Extension Manager to display an icon which is bundled with the extension. If you don't want your extension hosted on Extension Warehouse I'd just leave the extension_info.txt alone. Wait for official support for icons from other sources. The icon was added because we had easy access to that info when we query for updates. But it's clear that people want to present their extensions in the manager with icons/logos. It's noted.
-
Well at least I have the signing thing finally working, but it does seem a bit flaky I have to keep trying sometimes to get it to work.
I am wondering if my plugin creates or writes new files or folders within its plugin subfolder will this invalidate the signature/hash? I don't intend to create new .rb .rbs or .rbe files just .txt or log files.
-
I think I will probably go to a fully hosted setup on EW with my extension once I change up how I am controlling the licensing, this will probably increase my user base and is better in the long run.
The problem I am having right now is that when I go to edit any of my extensions the "agree to terms of use" checkbox does not seem to appear so I cannot click it and then preview my changes. I noticed this started happening about 2 months ago so I have not been able to update my listings for a while now.
So the interface keeps prompting me to click on agree to terms but I can't, has anyone else had this problem?
-
Questions about the operation (correct or incorrect) of the Extension Warehouse are best asked in the official forum:
http://forums.sketchup.com/c/extension-warehouseThose responsible are more likely to see the post there.
That said, The "agree to terms" checkbox issue seems to have come last month, but I thought it was fixed.
-
I just found an interesting issue this morning as I am further testing my plugin (Medeek Truss Plugin) with SU 2017. I have a sub folder called "logs" that I have placed some log files into (within my extension subfolder). These are updated when the plugin is used to create truss or rafter roofs, essentially keeping count of how many times the plugin is used to generate certain roof types.
When the plugin/extension is installed new these log files agree with hash and the plugin signature is valid however as soon as I write to these logfiles and change them in any way this causes the signature to appear as invalid in the extension manager.
These two files are named:
ROOF_TRUSS_LOG.txt
ROOF_RAFTERS_LOG.txtWhat would be the appropriate work around for this issue? Should I be storing these text log files in a different location?
-
Unless they haven't told us developers ??
The signing process is meant to 'hash' the contents of the following [initial] file-types:
rb
rbs
rbe
js
htm
html
css
[Until representations were made at the outset of v2016, only rb* files were being hashed and other potentially malicious file-types could slip through...]
Other file-types in the subfolder should be ignored.
Also any new file-types [including those like the initially-hashed ones] which are added into the subfolder 'post-signing' should be ignored ??Someone at Trimble like to comment...
Any more onerous changes have not been well explained
PS: Of course you can also write files into a Temp folder...
-
The signing process appears to be hashing my log files (.txt)
-
Well, then do not put them into the package until after signing ?
Or save your logs in a version independent folder like:
"%APPDATA%/Medeek/SketchUp/TrussPlugin" -
The signing shouldn't be including your .txt files. Can you send me an example?
In general I'd recommend you thread the Plugins folder like Windows' Program Files folder. If you have configuration files etc save them to the user's AppData. The extension update mechanism remove the old extension before copying over the new files. So that would also be an issue for you.
-
The plugin in question right now is my Medeek Truss Plugin. You can download it here:
http://design.medeek.com/calculator/sketchup/medeek_truss_ext.rbz
-
I heard from one of my coworkers that there appear to be an issue there the signing/uploading can fail at times when there are higher volume of traffic. I experienced this myself today when I tried to upload. At first I was getting just errors, but when I tried later with the same RBZ it worked fine.
A fix is being worked on.
-
It took me about 15 tries before I got it to take the other night. Hopefully there is a resolution since this becomes annoying very quickly. It does not seem to be dependent on the encryption type selected.
-
We think we have the cause identified.
-
Ugh... I'm suffering from this myself right now.
-
I have had this in beta and have reported it. My solution was to use a different browser then Firefox. Unfortunately even Edge was failing sometimes.
It doesn't matter what is the content of rbz file. The signing fails even with the simplest rbz you can think of. -
I'm not glad it is failing but I am glad that others have identified the issue and it is just not me going crazy or trying to submit flawed .rbz files. Thank-you for looking into this and working on a resolution.
-
We rolled out a patch we think should fix this issue.
Advertisement