I used to have a separate Cloudflare account with a separate DNS Zone for my internal services. Because CF PATs were free-for-all. They've improved this since, so now you can create a token scoped to a single Zone. If you really care about, you can move a subdomain to a separate zone with a child NS record, but I haven't tried it with cloudflare. If you are using something like AWS, you can create an IAM role that can only update a single DNS record.
Moving subdomains to separate zones can make sense for a small set of subdomains and all your certificates would be for names under those subdomains. It gets unwieldy if you have to create a separate zone for each certificate because the certificates don't share a subdomain. But this can be a solution in some circumstances. Thanks.
I own a Brother printer and was curious how the upload worked. Apparently, it is just screenscraping the CSRF token[0], and submitting the cert upload form[1] in the printer's admin web interface. It needs the printer's admin credentials for the upload to work.
The author also maintains https://disable-javascript.org/, which the pop-up links to. And has the exact script + titles used.
> You may want to consider linking to this site, to educate any script-enabled users on how to disable JavaScript in some of the most commonly used browsers. The following code uses scare tactics to do so.
> When added to your website, it will change the icon and the title of your website's tab to some of the most unhinged things imaginable once the user sends your tab to the background. Upon re-activation, the script will display a popover to the user informing them about the joke and referring them to this initiative.
And no, there are no dependencies in package.json either (other than devDependencies for tests).
Which cumulatively means a competent developer could probably port it in less than one day.
They almost certainly spent longer working out how to deploy and integrate the original JS and ironing out the problems, than it would have taken to port it in the first place.
That’s sad.
And then they definitely spent much longer making their optimised fast path for simple expressions. Which they probably wouldn’t have bothered with if they had just ported the whole thing.
As for trying things like embedding V8… this is getting ridiculous.
I strongly suspect no one had actually looked at the code, but had just assumed all along that it was much more complex than it actually was.
Java => Go is easier than JavaScript => Go because languages are more similar. That was a very line-by-line port.
Because I was paid by hour I took detailed notes.
I spent 601 hours to port it.
50k / 601 = 83 lines ported per hour, 665 per 8 hour day, but really 500 per 6 working hours a day. No one does sustained 8 hours of writing code daily.
I would consider that very fast and yet order of magnitude slower than your 5.5 k per day.
10x is not a mis-estimation, it's a full blown delusion.
I stand by my estimate, also having done interlanguage ports. I’m not saying any project of such size could be ported in one day, but this very much looks to be one of the more straightforward ones. Being a small project also accelerates things, as there are far fewer moving parts, concepts, &c. to keep in order.
I wouldn’t say that Java → Go is inherently easier than JavaScript → Go. There are more features in JavaScript that, if used, will make porting much harder, but they may well not be used. There’s a bit of async in this project, that’s probably the hardest bit, and maybe a little variadic calling. But comparing with your case, some challenges just aren’t there, such as inheritance and access control.
From a quick skim, I think perhaps 2000 lines will need no change beyond removing semicolons. And since this is mostly parser and AST sort of stuff, a lot of the rest is mechanical repetition and application of regular expression replacements or editor macros.
One note from your article, on fluent function chaining:
> This only works in languages that communicate errors via exceptions. When a function additionally returns an error, it’s no longer possible to chain it like that.
This is a Go limitation, not fundamental. (And Go is well known to be bad or at least verbose at error propagation.) Rust’s ? operator is an easy counterexample.
But trufflehog supports docker images already? The trufflehog readme has examples[0]
# to scan from a remote registry
trufflehog docker --image trufflesecurity/secrets
# to scan from the local docker daemon
trufflehog docker --image docker://new_image:tag
# to scan from an image saved as a tarball
trufflehog docker --image file://path_to_image.tar
That aside, I just tested against trufflehog myself. It did take about 10-15%longer for a scan to complete but this is expected. Layerleak is scanning any additional or deleted tags found for the digest while trufflehog only scans the one. I am proud of the project, so I am showing it off. If you dont like, dont use :)
Because it's an easy solution esp. to a rather new installer: setting up swap on disk (partition or file, if file which file system, if partition w/o encryption, ...). Zram: install one additional package and forget.
See also the "zram on Fedora" section in the article.
reply