Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
When building a BOOMR with the RT plugin, a
If MD5 is mandatory for using RT, it should be clearly stated in documentation. If this is not intendend, RT plugin should check if BOOMR.utils.MD5 is defined before using it.
I looked at this issue and I am considering a solution where we fallback to original string/url if
It should be something like what has been done as a fallback in hashQueryString() in boomerang.js:
Boomerang users should consider that they will have in their beacons the original values of the following beacon parameters:
So far I found 4 references of
There are 2 reasons we MD5 the URLs.
MD5 is not a secure algorithm, so there is no expectation that the checksum be safe from collisions or anything.
I think this change is fine as long as we document what will happen with and without the plugin.
Thank you @bluesmoon
My plan is to add small wrapper function in RT plugin for
I have one concern regarding having clean code because the code will look like:
On theory urlHash and docReferrerHash will not be always hashed version of a string but actual string. I believe this could be neglected if most of the people are using MD5 plugin.
Side idea (NOT to be implemented with this issue):
I am really interested in this issue and I am wondering how critical is for Boomerang and plugins to use another lighter hash function instead of MD5. Seems that in Boomerang project we use MD5 mostly for URL strings and it we could save some bytes if there is lightweight replacement of MD5. I found interesting ideas in internet and I believe that combined with some extra logic we can get okaysh uniqueness.
I found this checksum function on Stack Overflow: https://stackoverflow.com/a/3276730
I am not sure what is the probability for checksum collisions but we may get some good uniqueness if we append to the checksum