Problems with the Extension Warehouse Plugin Submittal system

Developers
1

Hello all,
I do not know if my frustrations are shared or not but I have been having some issues that I thought were probably universal and could be improved upon.

The first is the lack of discourse in the system. I just submitted a version of my plugin for review. I was pleased to see a reply email stating that it was under review. Then I received a rejection email with a stated reason, which is in error. Here is the rub. How can I explain that the person reviewing the plugin has made a mistake so that we can move forward? The email comes from a no-reply address. If the developers are not allowed to talk to the SketchUp staff, how are we supposed to solve issues?

The second issue with the process is that I have no control over the release of my plugin. I recently changed over the DNS supporting the processing of files through our plugin and I would have liked to have that switch coincide with the release of the new plugin for the sake of the users, but developers have no control over the actual release date and time because of the review process. This may be an isolated incident, or many of you may wish you could have a plugin approved and waiting for launch within the control panel. I will let others weigh in on this.

I hope this does not come off as a rant because I am hoping for some direction to help the SketchUp crew continue to improve and make a great product even better for the end users.

2 Likes
2

Welcome to the future - Homeland-Security - with not recourse to explanation.
A while ago I got a rejection because I had a Constant within a module named “TEMP”.
They said this would overwrite the system “TEMP” -
Of course it would NOT… and so they backed down.

BUT you do need to watch watch what you submit…

The main change in this new regime is that you must submit your RBZ file containing only RB files [in the subfolders[s]] - because if there are any RBS/RBE files it WILL result in a rejection.

And therefore the [tested] base-level loader-RB must refer only to the ‘file-name’ in the subfolder [with NO extension-suffix].
SketchUp finds either RB or RBS files etc, during loading [and therefore testing] - no need to specify the ‘file-type’.

PS: Do not be fooled.
You are offered choices which are poorly explained…

  1. You can publish your RBZ with NO encryption.
  2. You can publish your RBZ encrypted as RBS
  3. You can publish your RBZ encrypted as RBE
  4. You can publish your RBZ encrypted as BOTH RBS & RBE

Here are my thoughts…

=1. This is what you do if you are unconcerned about your Intellectual-Property [aka IP].

=2. This is what you do if you are relaxed about your IP, or have already exposed it to the hacking-community in earlier releases. - so it has already been potentially cracked, but at least it’s harder to extract your IP. from it.
Also see see item 4 below for more clarity !

=3. This is what you do with brand-new IP which you wish to protect from hackers.
The RBE format and its related ‘hash’ file is currently ‘uncrackable’ [although ‘they’ are working on it as I type]
BUT if you already published it as RBS it is already ‘exposed’…
This format has the additional ‘downside’ that it does not work in <2016 !
This severely limits your user-base…

=4, This is what you do if you are plain stupid !
I cannot believe this is an offered option !
[Trimble please note!]
If you publish it as an RBZ encrypted as an RBS, then it works in ALL SketchUp versions [including v2016] - despite what the new regime’s signing-portal might [incorrectly] suggest.
If you publish an RBZ containing both RBS and RBZ formats it works in ALL current versions - BUT it offers potential hackers extra help.
Because the RBS and the RBE versions will both be signed at the same instant, and that they therefore contain the exact same data, it offers a clear benefit to any hackers - they will know what both files ought to contain [after all, the RBS is known to be readily crackable!] - so why offer the illusory encryption, when offering <v2016 compatibility.

I raised this with Trimble ages ago [with some other ‘security loopholes’] - still no response…

3

Thanks and agreed.

The plugin was rejected because:

Load error: Could not find included file ‘CADspan/CADspan_loader.rb’

I opened up the rbz - then the CADspan folder, and wouldn’t you know it, the CADspan_loader.rb is sitting right there. It would be nice to have some means of letting their staff know there was an error. An email string within the publication portal would be great.

4

I assume you have requested encryption and therefore your path will fail, as @TIG has pointed out…

CADspan_loader.rb will be changed to either CADspan_loader.rbs or CADspan_loader.rbe depending on the level chosen, so you need to be using CADspan_loader without an extension stated in your code…

john

5

This is not “rocket-science”.
It has been documented before.
But, because Trimble chose a new draconian signing regime, and did NOT publicize the changes very well, then it is entirely their own fault - so please complain to them (big time!) [please].
:anguished:
I am fed-up with trying to get any sense out of them…

6

Argh, I see what you are saying now.

7

Will I need to change the version number to have them review it again, I loaded a new version with the rb stripped off but I have not received a confirmation as I had before?

Thanks