Oolite Bulletins

@cody @hiran

All reports about the danger of the site (if I understood correctly) boiled down to the fact that the site does NOT pose a threat, but does NOT prevent potential security problems. I tried to set the headers of the site in accordance with the security requirements (thanks @hiran for the report) - please try to evaluate if anything has changed... we will improve the characteristics of the site to get a good security rating - this has nothing to do with the content of the site, this just "server" settings.

<nods> Comment from D1 (owner of SSC):

Granted I don't have any malware/virus checking software monitoring my browser but in chrome or brave browser nothing is popping up for me on Win10. Hmm glancing through the site with devtools I didn't see anything pop out at me as a security risk. I wonder if its hitting on the files on the site ... for example I see OXZ, EXE. I would .ZIP/.7zip any files if possible just to avoid issues with downloading. And I noticed in a few places you get redirected to other sites when clicking on specific links.

Which SSC does a lot of this and so far no one has mentioned any bad stuff about links or files. But at first glance the site seems fine to me

@phkb, can we ask you to create another repository for us? We need to place artifacts somewhere... now it is on my VPS server and is available at https://artifacts.oolite.space. But we really want to post this information on GitHub, similar to our other projects. Placing this information in the oolite-web repo will not allow us to attach a sub-domain name to it - this repo is already participating in both GitHub Pages and CloudFlare Pages

timer wrote: ↑Tue Oct 17, 2023 3:20 pm

@phkb, can we ask you to create another repository for us? We need to place artifacts somewhere... now it is on my VPS server and is available at https://artifacts.oolite.space. But we really want to post this information on GitHub, similar to our other projects. Placing this information in the oolite-web repo will not allow us to attach a sub-domain name to it - this repo is already participating in both GitHub Pages and CloudFlare Pages

Timer is referring to the content of these releases:
https://github.com/OoliteProject/oolite ... g/releases

Where they are they are not directly browseable.

timer wrote: ↑Tue Oct 17, 2023 3:20 pm

@phkb, can we ask you to create another repository for us?

What shall we call this new repository? "oolite-expansion-artifacts"?

@hiran, is the PDF generation procedure an automatic thing when the ODT files are changed? Or do we still have to manually update the PDF's?

phkb wrote: ↑Tue Oct 17, 2023 9:52 pm

@hiran, is the PDF generation procedure an automatic thing when the ODT files are changed? Or do we still have to manually update the PDF's?

The PDFs are built based on the ODTs when Oolite is built. This happens in
https://github.com/OoliteProject/oolite ... ll.yml#L46

The PDFs in the repository are therefore not used at all. I had removed them, but then learned that they are required for local builds.
That's why they are back now but I put a banner in declaring that they are total and utterly outdated. This way, as a developer you do not have to bother generating PDFs manually, and we also do not need to check whether the PDFs have been updated. Eventually I'd like to include the Oolite version number these documents were generated for.

So your commit just providing the ODTs is exactly what I was aiming at.

phkb wrote: ↑Tue Oct 17, 2023 4:15 pm

timer wrote: ↑Tue Oct 17, 2023 3:20 pm

@phkb, can we ask you to create another repository for us?

What shall we call this new repository? "oolite-expansion-artifacts"?

looking here I read
You get one site per GitHub account and organization,
and unlimited project sites. Let‘s get started.

So I am trying to fire up github pages from the existing oolite-expansion-catalog. If that works we not need an additional one right now.

hiran wrote: ↑Wed Oct 18, 2023 4:33 am

looking here I read
You get one site per GitHub account and organization,
and unlimited project sites. Let‘s get started.

So I am trying to fire up github pages from the existing oolite-expansion-catalog. If that works we not need an additional one right now.

Looks like it worked. We have
https://ooliteproject.github.io/oolite- ... n-catalog/

But still need to check if the content is stable.

hiran wrote: ↑Wed Oct 18, 2023 4:33 am

So I am trying to fire up github pages from the existing oolite-expansion-catalog. If that works we not need an additional one right now.

it was immediately clear that we could use this repo... I just thought not to mix entities...
But, as you wish )

hiran wrote: ↑Wed Oct 18, 2023 3:42 pm

Looks like it worked. We have
https://ooliteproject.github.io/oolite- ... n-catalog/

But still need to check if the content is stable.

I hope in the next generation the site address will be changed to the current one )
Now GitHub Pages can be linked with CloudFlare DNS record.
Will you do it yourself? Well, or you will have to give me rights to the repo ))

UPD: oh... I looked in the repo and didn't understand how it was configured... it's hard to figure out without seeing the Settings section

timer wrote: ↑Wed Oct 18, 2023 4:38 pm

hiran wrote: ↑Wed Oct 18, 2023 4:33 am

So I am trying to fire up github pages from the existing oolite-expansion-catalog. If that works we not need an additional one right now.

it was immediately clear that we could use this repo... I just thought not to mix entities...
But, as you wish )

I just learned something. So far I thought one user or one organization can have at most one web page, and I assumed it was already gone with the website. Obviously wrong. But now that I know, I have some more content to bring online: the Oolite repository generates Doxygen documentation on every build. We can also publish that one so it is always browsable - not just for those that take the effort to download.

timer wrote: ↑Wed Oct 18, 2023 4:38 pm

hiran wrote: ↑Wed Oct 18, 2023 3:42 pm

Looks like it worked. We have
https://ooliteproject.github.io/oolite- ... n-catalog/

But still need to check if the content is stable.

I hope in the next generation the site address will be changed to the current one )
Now GitHub Pages can be linked with CloudFlare DNS record.
Will you do it yourself? Well, or you will have to give me rights to the repo ))

UPD: oh... I looked in the repo and didn't understand how it was configured... it's hard to figure out without seeing the Settings section

I am not yet clear whether the builtin workflow builds the site or the one I constructed. One would create a very minimal page via Jeckyl, the other one runs the full index via OoliteAddonScanner. If both of them get invoked in parallel, we may have a race condition.

Looking again at oolite-web and the concluded URL https://ooliteproject.github.io/oolite-web/ I am puzzled also. First of all it redirects to addons.oolite.space, second it does not show the expected site. So that one definitely is Jeckyl output. Which leads me to the bigger question: Currently what we have works like this:



AFAIK Cloudflare would act as CDN, which essentially would be a caching proxy server, wouldn't it? Now when I setup a caching proxy, I would not require write access to the proxied site. Let's assume I am setting up Apache httpd with it's proxy module and add caching, or I use something like Squid, nginx or haproxy.



So why does Cloudflare require privileges? What is the flow behind that?

hiran wrote: ↑Wed Oct 18, 2023 7:28 pm

Looking again at oolite-web and the concluded URL https://ooliteproject.github.io/oolite-web/ I am puzzled also. First of all it redirects to addons.oolite.space, second it does not show the expected site.

Just look at oolite-web repo Settings->Pages! And I'm sure everything will become clear. GitHub Pages is configured to use BRANCH only-media! addons.oolite.space via CF points to ooliteproject.github.io (CNAME DNS record). But, in GitHub, in the Settings for the oolite-web repository, the custom domain addons.oolite.space is specified - therefore, if you go to the address of the REPO Pages, GitHub itself will redirect you with code 301 to the custom domain specified in the Settings.
This is all about "FIRST our server" - GitHub, that serving subdomain addons. The CF here only performs the role of DNS for servicing the addons subdomain.

Well, the "SECOND our server" - this is a bundle from GitHub and CloudFlare:
1) the application from the CF is installed on GitHub in the oolite-web repo;
2) A Pages application has been created on the CF, which is linked to the only-static BRANCH! And also the oolite.space domain is configured on it;
3) The CF monitors changes in the GitHub repo through its application, and when something changes, it makes a deployment. But deployment occurs ONLY if the online-static branch changes!
4) CF acts as a proxy server

So I deployed TWO "websites" on the ONE GitHub repo oolite-web:
branch only-media -> GitHub Pages (as file server and web server) at addons.oolite.space (for big media files)
branch only-static -> GitHub (just as file server) + CF Pages (as web/proxy server) at oolite.space (for tiny html+css+js)

Do you still have questions regarding the current scheme of our site?

If I understood the GitHab Pages documentation correctly, there is no restriction on installing Pages per repo. That’s why I suggested creating a new oolite-web-artifacts repo and installing GitHab Pages on it and simply assigning a custom domain name to it. But you created another option based on the oolite-expansion-catalog repo. So... we can now simply link the artifacts subdomain to https://ooliteproject.github.io/oolite- ... on-catalog.

hiran wrote: ↑Wed Oct 18, 2023 7:28 pm

So that one definitely is Jeckyl output. Which leads me to the bigger question: Currently what we have works like this:

I didn’t even know that the Source for GitHub Pages could be Actions )
I'm studying the manuals...

hiran wrote: ↑Wed Oct 18, 2023 7:28 pm

So why does Cloudflare require privileges? What is the flow behind that?

CF require only install application to repo, which will be linked to CF Pages (to monitor events).

timer wrote: ↑Thu Oct 19, 2023 12:03 pm

So I deployed TWO "websites" on the ONE GitHub repo oolite-web:
branch only-media -> GitHub Pages (as file server and web server) at addons.oolite.space (for big media files)
branch only-static -> GitHub (just as file server) + CF Pages (as web/proxy server) at oolite.space (for tiny html+css+js)

Ah, two websites, two times different concepts but everything must be present to make it work.
Now I understand why I was confused.

timer wrote: ↑Thu Oct 19, 2023 12:03 pm

So... we can now simply link the artifacts subdomain to https://ooliteproject.github.io/oolite- ... on-catalog.

Yes, on that site it can be much easier. But the publishing flow must not go missing in the diagram.



and switching to Cloudflare Pages would not be so much different from an architecture point of view:



But be aware the HTML files that get published now are not stored in any repository. They are generated on the fly via some action - both for the oolite-expansion-catalog and meanwhile for oolite. Would we have to direct them into some repository before we can deploy them via the Cloudflare app?

timer wrote: ↑Thu Oct 19, 2023 12:03 pm

hiran wrote: ↑Wed Oct 18, 2023 7:28 pm

So why does Cloudflare require privileges? What is the flow behind that?

CF require only install application to repo, which will be linked to CF Pages (to monitor events).

Ok, the real answer is that we need to install the CF App if we want to publish to Cloudflare Pages.
Do we have any restrictions there we need to be aware of? I guess the traffic on expansions or even developer data should be fairly little.
Yet right now we have several shards, and it would be nice to have them available at a central location. Be it within one site linking to all the shards or placing them all on the same domain - I do not care much.

I'm trying to get the logo changes checked into GitHub, but my first PR has a failure on it, which appears to be released to the GitHub actions at the deployment stage. The most info I can find on the failure says:


This looks to be a permissions error, but I thought I had sufficient access to the entire project.

Any suggestions?

For the time being, I'll leave the PR where it is for debugging, but I'm OK if we need to delete it and resubmit. There are other changes to submit (to the Resources/Binary submodule), but given my lack of confidence submitting multi-module PR's I thought I'd do that one separately after the main PR is merged. Keeping things simple, and all that.

The deployment failed since you are not on the master branch.
If you look at https://github.com/OoliteProject/oolite ... 6672957702 you can see that it does not matter - what you need has succeeded.

In future I may remove that error message.