Extension Signing (.rbs)

I just jumped online to sign the latest version of my Wall extension:


I noticed that the option to use the .rbs encryption method has been removed without any advanced warning or notice to developers like myself. Why?

I am still signing with .rbs, imperfect as it is, in order to maintain some sort of backward compatibility with older versions.

Is there a separate link where I can access the old signing (.rbs) tool?

If not then I need to get my hands on the updated ruby scrambler for .rbe file types, I currently only have the .rbs scrambler for testing purposes.

I can migrate everything to .rbe if forced to do so but I would rather not if possible, at least not at this time.

Please reinstate the option to allow for .rbs encryption with the signing tool or perhaps provide a legacy tool that will allow for this (separate HTML link).

@thomthom @ChrisFullmer

It appears there is no .rbe standalone scrambler. So how do you quickly test your code while developing it without going through the whole online signing process?

Typically my plugins contain many .rb/.rbs files and when I’m updating them I’m usually only working on a handful of those files at any given time. Hence, the standalone scrambler is very useful and I can quickly scramble and then test my updates and debug incrementally.

Using .rb files?
Am I missing something in your question?

I don’t want to use .rb files since they are not encrypted and then anyone can read my code and take my intellectual property. I would like to use .rbs encryption in order to maintain backward compatibility to SU 2015.

I think what @jiminybillybob meant was why not use .rb during your own coding and testing, but perhaps what you mean is that you have testers to whom you don’t want to reveal your IP?


To be honest I don’t know how to run the extension(s) unless it is encrypted.

For example within my code I need to load up other files:


Notice that the .rbs extension is hardcoded into the filename.

Perhaps there is a better way to do this?

You don’t need the file extension, just leave it out and it’ll look for that file name ending with .rb, .rbe or .rbs (in that order).


Well… shoot, how come no one ever pointed this out before:

You do not need to include the file extension on the path. This method will look for .rb first (unencrypted) and then .rbe (encrypted) and finally .rbs (the deprecated scrambled format) files. See the “Distributing your Plugin” article for details.

I guess I’ll make the switch to the .rbe format/encryption, some of my users are going to be very upset.

It’s one of the differences between Sketchup.load and Ruby’s native Object#load.

1 Like

How about this line of code:

medeekwall_Extension = SketchupExtension.new("Medeek Wall", (File.join(File.dirname(__FILE__),"medeek_wall_ext","medeek_wall_load.rbs")))

Can I leave the extension off or should I change it to .rbe?

Leave the extension off. Most of the time, you’ll be testing with .rb files. Only encrypt it and test the encrypted files when you’re ready to make a public release. You shouldn’t have to change anything in your code for it to work with either .rb or .rbe files.


I’ve switched to the .rbe encryption method.

(Shaking my head bemused wonder) :confused:

Refer to the official documentation for Sketchup::require …

.require(path) ⇒ Boolean

The require method is used to include encrypted and nonencrypted ruby files. This is an alias of the Sketchup.load method.

You do not need to include the file extension on the path. This method will look for .rbe first (encrypted) and then .rbs (the deprecated scrambled format) and finally .rb (unencrypted) files. The loading order was changed in SketchUp 2016 when the new .rbe encryption was introduced. Prior to SketchUp 2016 the loading order was first .rb then .rbs.

Note that it and Sketchup::load are aliases …

The load method is used to include encrypted and nonencrypted ruby files.

You do not need to include the file extension on the path. This method will look for .rb first (unencrypted) and then .rbe (encrypted) and finally .rbs (the deprecated scrambled format) files. See the “Distributing your Plugin” article for details.

These descriptions have been there for 4 years now. And even before the changes when rbe was introduced, it still told coders that their code does not need a file extension when using this method (since ver 6 or earlier, ie whenever RBS scrambling was introduced which I know was before version 7.) So let’s say that this information has been around at least 13 years.

In addition, since Sketchup::register_extension causes a call to the hidden method SketchupExtension.load(), which just calls Sketchup.load() … you do not need to use a file extension in the second argument of the SketchupExtension class constructor method call.

Thirdly, the SketchupExtension class will determine the absolute path of the extension. (I suggest you read the "extensions.rb" file in the SketchUp "Tools" subfolder (of it’s %ProgramFiles% folder. Ie, it’s binary application folder.)


These two statements are mutually exclusive. RBS is not encryption per se (it scrambling at best) and has been known to be cracked for many years even before RBE was introduced.

Continuing to publish RBS content does 2 things.

It gives away your IP. I could read it if I desired and do not even need a “cracking tool” or RBS unscrambler. But such RBS unscramblers are out there on the web if you wish to search for them.

The other thing it does (since RBS allows access to the unscrambed code) is give crackers an idea of how the RBE encryption is done. (One of the reasons why the British were able to crack many of the Nazis Enigma codes was because they included the same H.H. salutatory at the start of every message. How dumb can you be! [referring to the Nazis])


Well the good news is I have officially moved to .rbe now, better late than never.

Sometimes my mentality of “don’t fix it unless it is broken” probably gets me into some trouble in the long haul. Approximately five years ago when I first started coding these plugins I was probably not aware of this statement in the API or perhaps it was not even posted yet. Once I got into the practice of hard coding the file extension there was no reason to ever change that or a reason to look up the API method to check for new documentation. I guess at some point I should review the entire API just to check for things I might be doing wrong or inefficiently. The API is constantly evolving as we all know.

Also the fact that I don’t have to hard code in the file extension actually speeds up my testing/prototyping regime, I guess I’m still learning… always the student and never the master.

1 Like

:+1: :white_check_mark:

I’m still a little ticked at SketchUp for no advanced warning of this update. Please give us the courtesy of at least a one week notification before making such drastic changes, I think we at least deserve that.

1 Like