I am trying to get an .rbz signed, but am getting these errors:
I think everything is right. Can someone have a look?
jf-rubytoolbar-16r1.rbz (8.6 KB)
I have had this exact error too.
BUT on some other RBZ’s, with a similar file structure of nested folders inside the RBZ, then everything is peachy.
So it is currently totally ‘fubar’ !
I have sent messages “elsewhere” [to @ChrisFullmer ] to get this resolved.
But nothing for >>= three days… 
There are a number of other serious issues, and misinformation too…
so please login “elsewhere” and read them… if you can…
I did manage to get it signed. As far as I can tell, it has to do withthe path to the loader file:
This could not get signed:
dir = File.dirname(__FILE__)
ext = SketchupExtension.new("Ruby Toolbar 2016", File.join(dir, "jf-rubytoolbar", "main.rb"))
This did get signed:
ext = SketchupExtension.new("Ruby Toolbar 2016", File.join("jf-rubytoolbar", "main.rb"))
Aha. I see - perhaps relative versus full-paths…
BUT, I tried that change to the loader’s code and it still fails…
I am not sure it the absolute path that causes it to fail, but I suspect it is the use of variables in the SketchupExtension.new method. The arguments might need to be String objects that are decipherable by the signing software without executing the extension.
Thanks, I have seen your post "elsewhere’…
But I can’t get it to work, even with a simple string “relative path” !
Let’s continue this conversation “elsewhere”…
I tried signing a package and am getting the following error
I can get it to sign if I don’t choose an encryption method, but it fails with either rbe and rbs request.
Tried re-signing the extension (with rbe enryption) that was previously signed when SU2016 was released… it now fails as well.
sigh…
I also got this error.
Perhaps the Signing Portal is ‘down’…
Try later…
I had found a couple of glitches…
If an RBZ is made from a ZIP its suitability for signing can depend on the program used to make the ZIP.
I have tested several programs…
Although SketchUp will happily process ALL such RBZs, the Signing Portal can occasionally fail - reporting an error that there can only be one folder within the RBZ, BUT of course there IS only ONE !
This is also hard to pin down because RBZs made with ANY of the programs will often get signed OK - just now and again it throws a false error.
The programs I have discovered that occasionally mess with the Signing Portal’s ‘brain’ are the PC’s IZarc and ALZip.
The following have thus far always given good results: Windows own ‘Add to Compressed Folder’, 7-zip, WinRar.
Interestingly a ZIP made with each of the five using the same files/folder and compression methods etc can vary in size by a few bytes and the file structure within them also varies - particularly in the type that fails the signing checker.
However, they ALL extract OK into SketchUp or as ZIPs…
Perhaps the gurus are looking to tweak the checking to work properly !?
Signature page doesn’t work yet.
As Palo said it works only if you don’t select any encryption type. Otherwise it breaks.
It is strange that they haven’t fixed it yet. Does anyone have idea how to contact them?
I’ve sent mails to extension warehouse few times, and only once got some answer.
Marija
I have been in contact with @ChrisFullmer and sent in a broken snippet of code for analysis.
It appears that the extension signing is working again.
I’ve tested also both encryption methods today, and it seems to be working ok.
Hi all,
I have just been trying to get the first signed SU2016 / EWH compliant update of my plugin ready and encountered some issues with the signing / approval process.
It seems that SketchUp now requires the root .rb and plugin folder name to include an underscore character, otherwise the approval process fails and the “Load Unidentified Extensions?” dialog pops-up (in Approve mode), even for a successfully signed extension. Has anyone else had this issue?
According to Page Not Found | SketchUp Extension Warehouse
We strongly recommend prepending your extension name with your initials or company name…
However it seems this is now being treated as an absolute must by SU2016! Is that an official policy or just an unintended consequence of some over-zealous validation? This is pretty annoying as I have had to change the plugin loader and folder name, so when releasing updates my plugin will now need to check for previous versions of itself that use the previous folder name, and delete them, otherwise both will try to load and there will be clashes.
Dave
There were issues with having this in the RBZ:
MyWidget.rb
MyWidget/MyWidget.rb
Because of two files with the same ‘name’.
I thought this was resolved ?
BUT…
This is easily fixed by changing the main code file’s name, which is called from the ‘loader’ RB.
So you have:
MyWidget.rb
MyWidget/MyWidgetCode.rb
There is NO requirement for an _
I have several signed RBZs without any at all…
Although I do appreciate the annoyance of the way the signing process has been handled thus far…
For example try to get a simple plugin RBZ signed, with a matching subfolder.
If the subfolder is empty it fails.
Adding a spurious NAME.hash file into the RBZ lets it be signed !
Go figure…
Hi TIG,
This isn’t quite the issue I’m having:
I have something like:
MyPlugin.rb
MyPlugin/MyPlugin_loader.rb
With the original name of the plugin “designph”, for some reason the signature approval is failing, but adding a prefix and “_” to the name seemed to fix that. I tested many different changes, stripping out various bits of code, changing filenames, removing various files etc etc, then re-signing, to try to isolate what was blocking the approval and changing the root and folder name was the only thing that consistently worked.
I have since done some further tests and you are right, it seems the “_” is not necessary, other variants of the name also seem to work, however with the original plugin name it is still consistently failing the approval process. Any idea why this could be? I really don’t want to change our plugin name as it will just cause more hassle.
cheers
I understand that the ‘same-file-name’ issue was reported before v2016 hit the streets, AND I believe it was fixed - although because of that I ensure a different name is used anyway !
BUT another issue I have previously reported is that it can depends= what software makes the ZIP that you convert into an RBZ.
Oddly they all produce slightly different compressed files.
And sometimes some do not get signed whilst others do.
I found these apps work without errors [thus far]:
Widows built in “Send to >> Compressed (zipped) folder”
“7-Zip”
While the others occasionally mess up.
And they then report nonsensical errors when the RBZ is offered for signing.
What are you using to make your ZIP >> RBZ ?
Perhaps swapping to another app will fix it ??
Right, I think I got to the bottom of it…
Looks like it might be a variant of the “same file” issue:
I decided to clear out my Plugins folder and trash the preferences file and see where that got me -
I had another folder in the Plugins folder which contains an optionally loaded secondary plugin I use as a beta-testing environment, which is named “designph_beta”. Renaming that so that it does not have the first part of the name in common with the main plugin seems to fix the issue.
This new regime is proving to be quite a headache… 
[FYI: I use a Mac OS X Automator action called “Create Clean Archive” to make my ZIPs so Win users don’t get all the Mac hidden files]