OK, so about the proposed security page

Hopefully someone better at design/UI/UX than I can help me understand the optimal layout for this

Separately from this, I can make a PR that at least includes the CLSAG blag post... when could this get built/deployed?

I need to coordinate this datetime with OSTIF, who will also be posting the report on their own site

As a courtesy we'll be releasing the report simultaneously-ish

UI/UX?

where is rehrar?

To be clear, let's separate the two projects here

Project A is posting the CLSAG blag post and the audit report in a PR

Project B is developing a security page with VRP information and all audit report links

Project A needs to be coordinated with OSTIF, who say they would be ready as soon as Friday

Project B can be done at our convenience

(but after Project A)

If I make a PR for Project A, how soon could it be deployed and live?

sarang: Feel free to make a PR for A. There seems to be no clear agreement about how to show B. I can review A as soon as you make the PR, then we can ask luigi to merge and we should be able to deploy it soon after if necessary.

About B. I think we can make a simple page divided in two, with a VRP section and an audits section, then we can replace the "Vulnerability Response" link at the top of Getmionero with a link to this new page. We should also link to it from the MRL page

I can work at B as soon as we decide what we want to do.

.merge+ #1104

Added

Yo

What is the best location in the source tree for the audit PDF, with the understanding that more will be added eventually?

And what's the proper way to reference these relative URLs in the markdown source for the blag post?

e.g. MRL papers live in `resources/research-lab/pubs`, but those don't need to be linked in posts

I would say resources/research-lab/audits

OK; how to reference properly from the post markdown?

will a simple `href` to `/resources/research-lab/audits/...` work as expected?

Or is there some magic incantation required because of the underlying engine

downloads.getmonero.org could be required. Let me double check, i'm not sure.

Of course we can move things around later if needed, but that sounds more annoying

ok

Putting them in the blag assets directory would work nicely, but that doesn't seem like the best place

yeah use simply `/resources/research-lab/audits/...`

neat ok

Almost finished with the PR, but I can't push it until the release date

(since the report can't be made public until then)

Does Friday (tomorrow) work for that?

No problem for me

Great

I'll coordinate that with OSTIF

Sure, jsut ping me if i'm needed

about downloads.getmonero i got confused, that's the separed box we use for downloads

Many thanks

(downloads of the binaries only)

np

I do remember there maybe being something about those existing PDFs being hosted on downloads, but perhaps I'm misremembering

yeah there used to be some more stuff there IIRC, that's what confused me

Ah ok, but that got moved?

No reason to be hosting small stuff like PDFs off downloads

The PDFs of the MRL are and were hosted in the research-lab/pubs folder AFAIK

Yeah, but for some reason I recall someone like fluffy or binary mentioning something about there being some odd way they were hosted

oh yes we have two PDFs in downloads

ok

Doesn't seem to be of consequence here, at least

the "annotated whitepaper" and "Brandon Goodell's Whitepaper Review"

got it

I think fluffypony made a list of what's in the 'downloads' box some time ago, would be good to have that list handy. i'll check

Would it make sense to move those PDFs?

Just for consistency, and to make any changes easier in the future

(not for this PR, of course, but a separate one)

I think so. I would be ok with that.

Does this mean the PDFs aren't even in the `monero-site` source tree?

(If not, that's a perfect reason to add them!)

correct

If nobody has nothing against it, i will add them both to /resources/research-lab

actually what might be good is to turn the downloads site into a Git repo

I'll work on that today

Still seems optimal to have research-related PDFs in a single location

IMO

In particular, it means they're in a repo that is managed by non-core people

good indeed.

(even though core does the builds)

Still seems optimal to have research-related PDFs in a single location <- yes i would move it either way

re: PDFs, we don't have any PDFs on downloads.getmonero.org except the CN whitepaper and the annotated CN whitepaper

and that's more for historical reasons

oh I see ErCiccione mentioned that already

Yeah, that's what we were referrring to

Moving those to the same place as the other MRL stuff seems reasonable

Of course, the newer preprints are just links to IACR anyway

yeah we can just have a redirect

I'm making the PR right now (writing the commit description as we speak) let me know if we shouldn't do it for some reason

but we had also discussed making the source to those IACR preprints available on a repo too (they're on my github right now)

do it = move the PDFs to the monero-site repo

(and noting that those IACR links are external)

sarang: i think we can move forward with that once those sources are uploaded somewhere

we were talking about a dedicated repo in monero-project IIRC

Yeah, it's on my list but I just haven't done it yet

that's on me

I still like the idea of keeping the IACR PDFs as external links

Alright, no worries. It's not prioritary

as long as they're marked and the source is available (which it is)

yeah specifying when links are external is in my TODO

"IACR could be compromised" is a good counterargument, but seems unlikely

and I don't think there exists a site that is viewed regularly by more security experts =p

created the repo

that was fast

Oh, it's empty

nvm

not that fast =p

lol

fluffypony: what is supposed to be in monero-downloads repo?

the downloads

once I've finished scp'ing them from the server

:O

but not CLI / GUI bins I guess?

else the repo will be huge

yes all of the bins

that's fine

it's not like everyone needs to grab the repo

What's the advantage of having them in this repo?

As opposed to packaged on the `monero` repo?

Maybe I'm missing the point

sarang: we don't want the monero repo to be like 500mb

if github allows that I guess

git lfs

and it allows us to deploy changes a lot more easily

ah ok

isn’t the bin archive over 10gb?

> Repositories have a hard size limit of 100GB.

ok should work

selsta: I'm excluding blockchain.raw

since that's created by the daemon

also I just noticed that it's not been auto-updated since we moved to the new environment, cc pigeons

.merge+ #993

Added

fluffypony: so the point is that the actual server will have its content deployed right from the repo?

Instead of via some other manual method?

it's still manual deployment from that repo

in case the repo is compromised

but yes

Right, not _totally_ automated!

But from the repo at least

Posted my usual update on reddit: reddit.com/r/Monero/comments/i0mpk2…neroorg_updated_massive_performance

A lot of nice stuff

aaand automod blocked it

hah I take back my totally optimistic size estimate - it's more like 19gb excluding blockchain.raw

still, that comes in well under GitHub and Backhub's limits

fluffypony: the problem is that everyone who wants to add some PDF to the repo has to download 19GB if I understand this correctly

not sure if ideal

selsta: you can ask someone else to add it, or add it through GitHub's web interface

oki

it also makes it easier to deploy a new Monero website if anything happens

selsta: PDFs shouldn't be uploaded there

we are moving the only two which were there to monero-site

should we even bother redirecting or just leave them in that repo for historical backlinks to it?

any old backlinks aren't going to change now

I would just leave them there

kk

I just submitted the updated sitemap to google. I think they would re-crawl it anyway, but a little ping won't hurt

also one nice thing about this repo is that I just noticed nobody did the source tarball

for the 0.16.* releases

We also don't give a link to download it from the website AFAIK.

yes but it's used by the auto-updater

if you build from source

fluffypony: hi sir do you happen to have a box for `xmr-pr`

our beloved bot needs a stable dedicated home

sure - pigeons should have a spot on one of the Monero servers

he just lacks time atm

I'll chat to him when he's around

oh ok cool no hurries

fluffypony: the problem is

gui does not allow building without git repo

soo the sourceball is useless

until we fix this we didn’t create one

ok but for CLI?

yea CLI should work

I can do one for CLI in the future

Small PR to fix a link on an old post: monero-project/monero-site #1110

Looks like the preview build doesn't show it since it's an older post, so I cannot test it

Seems straightforward.

.merge+ #1110

Added

sweet

What I see on the blog page: usercontent.irccloud-cdn.com/file/PX0dP5uw/blog-links.png

Anyone else get this weird link spacing?

on web.getmonero.org/blog

try to clean cache

looks good here

Can the HTTP responses for these pages specify cache expirations?

yes

but it's in our best interest for them to be long-lived (in general)

Isn't there a middle way? i think most of the people don't even know how to flush their cache and they end up weirded out by some broken css or something else

having a shorter expiration time for the css would make sense

other resources like images can stay the same