Extension Signing

Dan Rathbun · 17 Nov 2016, 21:50

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.)

medeek · 18 Nov 2016, 09:58

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.

thomthom · 18 Nov 2016, 13:30

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.

medeek · 18 Nov 2016, 15:39

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.

medeek · 18 Nov 2016, 15:44

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?

Dan Rathbun · 18 Nov 2016, 20:18

Questions about the operation (correct or incorrect) of the Extension Warehouse are best asked in the official forum:
http://forums.sketchup.com/c/extension-warehouse

Those 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.

medeek · 19 Nov 2016, 18:38

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.txt

What would be the appropriate work around for this issue? Should I be storing these text log files in a different location?

TIG · 19 Nov 2016, 19:46

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...

medeek · 19 Nov 2016, 21:42

The signing process appears to be hashing my log files (.txt)

Dan Rathbun · 19 Nov 2016, 21:59

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"

thomthom · 21 Nov 2016, 11:46

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.

medeek · 21 Nov 2016, 13:50

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

thomthom · 21 Nov 2016, 20:43

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.

medeek · 21 Nov 2016, 23:13

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.

thomthom · 22 Nov 2016, 10:45

We think we have the cause identified.

thomthom · 22 Nov 2016, 11:15

Ugh... I'm suffering from this myself right now.

tomasz · 22 Nov 2016, 12:23

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.

medeek · 22 Nov 2016, 15:09

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.

thomthom · 23 Nov 2016, 21:05

We rolled out a patch we think should fix this issue.

tomasz · 24 Nov 2016, 15:06

@thomthom said:

We rolled out a patch we think should fix this issue.

Thanks. I confirm that the fix works for me. I can sign a plugin using Google account from Firefox without a problem.