@spdegabrielle I think what Laurent means is that you can execute arbitrary code in DrRacket, so if you want to do something nasty to someone who uses Racket, just inject some nasty args into a racket: URL

@pocmatos Is examples the one from scribble/example ?

The relevant paragraph from the docs must be:

@popa.bogdanp Looks like you’re keeping a snapshot for each day, quite impressive. Are you checking for differences or equality or are you keeping all contents for each day? Do you know how heavy is one snapshot and how much memory it will take you over 5 years?

If memory becomes an issue, I suppose you can keep daily snapshots for (say) 6 months, monthly snapshots for 2 years, then biannual beyond.

@spdegabrielle Yes, what @jesse said. Even just a limited protocol like opening files could be harmful due to background expansion in DrRacket for example. Fortunately, it is currently sandboxed so you can’t make it write/delete files in particular, but you can make it read files. So one attack vector would be to make the user download a rkt file, then use the drracket: protocol to open this file (assuming a default download location) in DrRacket. If the file contains nasty syntax code (executed by background expansion) then it can read any of your files. If there’s a security hole in background expansion (which you should assume there is), it could use that to do whatever it wants, including sending your data to some remote server.

@pmatos Add [print-as-expression #f] to the parameterization.

Looks like one day is about 1.5GB, so that’s certainly fine for now. I guess it depends on how fast pkgs will grow :slightly_smiling_face:

~Btw, trying to read pkgs-all with a text editor (gedit) kill it, because there’s no newline so it tries to load the whole first line into the GUI. I’m sure other editors will suffer too. Even less doesn’t like it too much when trying to go to the end of the file.~ (edit: well, apparently, that’s just how catalog-copy works, so not your doing). For ref, this adds newlines (heuristically): sed 's/\(("[^"]*" \.\)/\n\1/g' pkgs-all > pkgs-all-nl

@soegaard2 right! That was the problem, quite surprising that by default i didn’t get the expected value. Will take a look at the docs you referenced. Thanks!

@mflatt using continuation-mark-set-first repeatedly is very slow (22s) when (current-continuation-marks) is passed in, but very fast (0.5s) when #f is passed in, even though they are supposed to have the same effect. Is this a feature that should be documented (#f is fast, use it!), or a bug?

This is on Racket BC btw. A similar effect can be seen in Racket CS, but the difference is not as pronounced.

I use a <https://github.com/Bogdanp/racksnaps/blob/master/deduplication.rkt|content-addressing scheme> to deduplicate the content on the assumption that most packages change infrequently so daily growth should be much less than 1.5GB. Over the past week, it looks like the size of the “store” has grown about 100MB.

That’s pretty cool !

But can’t you use the versions.default.checksum argument of the package’s info for this purpose instead? (For github packages at least, this checksum appears to be the last commit on git. Also note that this differs from the checksum argument)

For git packages, I probably could assuming I kept that information around. But because I build package archives of every package first, the checksum ends up being the checksum of the zip file, which can change even if the zip’s contents don’t change between builds because zip files record the modification times of the files they contain.

It just seemed simpler to treat every package as if it is just an archive and perform deduplication at the end, even though that ends up taking a little more time.

fair enough

I don’t know if “feature” is the right word, but it’s expected, and I’ll adjust the documentation.

Just to be clear; BC, 3m and regular are all the same thing right?

“regular” and “BC” are the same thing in this context. 3m refers to a particular mode of operation/compilation of Racket BC

I’m assuming BC = before chez

yes

name due to @ryanc

Thanks

Also "*b*yte*c*ode" and "*b*ased on C", but yes, I think "*b*efore *C*hez" is the official expansion.