As some of you may know, recently, Glowkit has moved to a patch-based system. We feel that it’s going to be far easier to work with Glowkit on a development and compilation basis by adopting this method, and it also allows us to base upon much more recent Bukkit forks - such as the one maintained as part of PaperSpigot.

If you’re just a Glowstone user, this has no immediate effect on your experience. Contributors and maintainers, though, should bear the following steps in mind:

• Clone the repository recursively, to include the submodules (git clone --recursive)
• Run applyPatches.sh (Windows users can use Git Bash, or Bash for Windows 10)
• Make your changes in the Glowkit-Patched directory
• Compile, test, and so on
• Commit your changes
• Run rebuildPatches.sh
• Commit your changes and push them

We completed 16 tickets and pull requests last month. See here for March’s project board.

This month, we’ve decided to set up two project boards.

• April 2017, in a similar vein to last month’s board, will track everything we do this month.
• Intelligence Update will track all tickets related to mob AI this month.

Supporting multiple versions (even if it was just one at a time) would certainly be a very neat feature. One that would set us apart from all of the craftbukkit forks/clones, in fact. However, I still think we should go back and move forward; Mojang implements Minecraft features on a rolling basis and we should do the same features in the same order in order to keep up with expectations.

That doesn’t mean the protocol implementations can’t be separate, though.

@mastercoms Yeah, that works. Now we need to just get some tickets set up.

I never actually saw that - How did it work?

Well, do whatever you feel is best for this. But we definitely need to start using the milestone system. That would be the best way to compile these “lists”, I think.

Of course, but they’ve proven that they care about the project.

Yeah, that’s the main problem as I see it. I wouldn’t say we don’t have a team, though. Don’t forget about all the people that are allowed to contribute directly and manage issues - the contributor group.

But you’re right, this wouldn’t work without a handful of dedicated developers. I can only think of one or two people that would be interested in adhering to it right now.

If we split things into milestones, we can just prioritise the current milestone. Maybe even have a branch for it? I’m not sure what your preferred method of organisation is.

There’s nothing to say we can’t deal with the other stuff as well, but we should prioritise our… priorities…

…you know what I mean.

It’s not the entire expectation; the expectation is feature parity, and I feel like doing this by increasing version is a much easier way to keep people focused.

If you’re using Glowstone, we’d appreciate it if you’d help us to test out plugins!

We’ve set up an Airtable base, which is powered by a form. It’d be great if users could post their experiences by filling out that form!

If you’d like to view the compatibility table, just click here.

---

If you’d like to discuss plugins and their compatibility with Glowstone, feel free to make a topic as well.

This is a post to notify everyone of a possible intrusion relating to the forum. I have provided a full report in an effort to be as transparent as possible.

Report

Tuesday, 25th July 2017

Momo noticed that the forums were down. I was asleep at the time, and did not get the message until the morning - it was late at night.

Wednesday, 26th July 2017

I got Momo’s message, and investigated the problem. I assumed that Redis was down, so I restarted it and updated and restarted the forums, and everything appeared to be working just fine. I noticed that the plugins we had installed were removed, and so I reinstalled them. No configuration data was lost. I also noticed that a couple of posts I had made a day or two before that were missing.

Thursday, 27th July 2017

I noticed that a Nextcloud install on a different VM (my personal install) was using the same database server as a memory cache, despite being configured not to. I reconfigured Nextcloud and removed all of its cached data from the database. Nextcloud did not touch any actual NodeBB data, so that wasn’t the cause of the issue.

At this point, we realised that data going back around a month and a half had been lost. Fearing further data loss, I set up some cron tasks to force Redis to save its data and save a backup every hour. I checked the Redis logs and there was nothing abnormal in them, so I assumed the problem was with NodeBB and continued investigating with Momo.

After reading over NodeBB logs, events and errors, we found nothing of interest.

Friday, 28th July 2017

At around 4AM BST, Momo became available again and continued his investigation. He discovered two things:

• Redis was accessible (without a password) from outside of the network
• Redis was failing to save any data due to an error, thus disabling the forums

At around 8:30AM BST, I came online and restarted my investigation.

Due to an issue with Proxmox (the hypervisor I use to manage containers and VMs and keep things compartmentalised), it turned out that the firewall I had configured was not doing its job - instead of dropping all disallowed traffic as it was meant to, it was simply allowing everything. I fixed this problem by setting up a firewall directly on the storage container and this secured it from the outside.

I noticed that Redis was attempting to save data to /var/spool/cron, which is not its usual location. It did not have permission to write there - which is why it was failing to save data. Upon further investigation, I noticed that it was able to overwrite the crontab I had set up earlier - and had done so with the entire contents of the database. At this point, I took down both Redis and NodeBB so that I could fix things up.

I wiped all of the cron storage directories and reinstalled cron. I double-checked the Redis configuration and found nothing unusual, so I restarted that as well. It started up correctly and did not attempt to write to /var/spool/cron again.

I used a GUI tool to inspect the Redis data, and I noticed that the data I had removed previously (from Nextcloud) was still present. I removed it again, and I noticed an extra key that I hadn’t seen earlier: It was a randomized key, containing a crontab entry. This crontab was configured to download a shell script from an IP address and execute it.

I grabbed a copy of the script myself and took a look at it, and it simply downloaded a cryptocurrency miner and ran it. Upon investigation, it was clear that this crontab had never been run, and that the attack was supposed to play out as follows:

• Search for compromisable Redis servers
• Add a key with a crontab entry to run the script
• Use the CONFIG SET command to overwrite the crontab with the database
• Wait for the cryptocurrency miner to start

The cron daemon I’m using performs very strict syntax checks and did not run the crontab - as soon as it realised there were invalid “entries” in the file, it errored out.

I removed the key from the database and made sure the forum was running correctly.

Exposure

While there was absolutely no evidence that this attack targetted NodeBB or even Glowstone specifically, precautions should always be taken. As NodeBB stores its entire database in Redis, all of the data therein was exposed. It’s impossible to say what the attackers may have taken - if anything - but as always, users should take all of the necessary precautions.

NodeBB stores passwords using bcrypt. This is an industry standard and currently considered very secure, but we still advise users to change their passwords - both on the forums, and on any accounts they own elsewhere that may be using the same password as their forum account. Note that any other data provided during registration and profile modification will have been accessible as well - for example, email addresses.

I have revoked all the user tokens from GitHub OAuth, and reset the client secret, to protect users’ GitHub accounts.

---

I’d like to apologise for this intrusion personally - it definitely shouldn’t have happened, and while I’m amazed that it did, it is my responsibility. Please don’t attack or bug any of the other staff members - they don’t have direct access to any of this stuff.

As far as I am aware, everything is now secure and in working order, but I’m going to continue monitoring and testing throughout the day. Feel free to contact me if you have any questions.

This post was mirrored from the site.

Last day of the month, and I finally got my PR done. Sorry I’m so late!

@dindu-nuffin

…you used http://contributor-covenant.org , a site that has been used and pushed by insane SJWs.

Yup, I’ve seen this too often. The Node community, the Ruby community… yeah. There’s a little more to it than that, though.

Since the maintainers put the second line in the code of conduct…

You’re referring to the following, right?

Part of this problem lies with the very structure of some projects: the use of insensitive language, thoughtless use of pronouns, assumptions of gender, and even sexualized or culturally insensitive names.

While I agree with the sentiment you got from that paragraph, it’s not actually in our version of the CoC - and I don’t think it’s in the “official” version explicitly. You can check here for the latest version of what we’re using.

Use welcoming and inclusive language. - that can be anyone’s opinion.

Subjective, yes, to a point. I think that may be intentional, though - not just to target the perspective of the “victim”, but also to make it easier to apply to the situation of each individual project. I think a lot of this comes down to enforcement - and yes, I have seen projects pressured into over-enforcing this clause.

That said, that’s specifically listed as an example of behavior that contributes to creating a positive environment - deliberately subjective because, in my opinion, it makes people think of the best things that they could say in the situation, rather than some idea of what we require from them.

Be respectful of differing viewpoints and experiences. - again totally subjective

I wouldn’t say this is subjective. A lot of people assume this means that you can’t challenge viewpoints or discuss them, but there are ways to do that respectfully. For example, instead of being confrontational and proclaiming that xyz viewpoint is wrong, you could ask Why do you believe xyz? - and if you don’t agree with them, just say something along the lines of I disagree with you, but I respect your right to believe that.

That said, we aren’t really about general discussion. It’s going to pop up, as it does with every community, but we prefer to focus on discussion that’s specifically related to the project, so we don’t anticipate having to moderate situations like that very often.

Show empathy towards other community members. - Totally un-needed, and also is subjective.

Empathy is a little subjective, yeah, but it’s not hard to give empathy. If someone is in a bad situation, and you are involved in the conversation, you can simply say something along the lines of Yeah, that sucks or Sorry to hear that or something similar - or if not, you don’t have to engage at all. Up to you!

This code of conduct also doesn’t take into account how speech can mean one thing in one context, and completely another in a different. The code of conduct could be used to spin the speech and kick a member off the team.

Interesting point. See the next section.

---

I take a lot of these points as they come - I see them raised a lot, and some of them are issues that I have also had with this exact CoC. That said, I think a lot of this comes down to enforcement.

A CoC is only half of the story - If you have a project which has people with malicious intentions, people that are ignorant of problems with a CoC like this, or just people that don’t care about the community, things can go bad quickly because the CoC is so open-ended. Sometimes, politically-motivated people may try to pressure staff to achieve the outcome that they want - a great example of all of this is the infamous eggplant controversy in the Node community.

I just want to make sure that you (and everyone else) are aware that we know about these issues. We are not interested in censoring certain types of speech, and we’re not interested in pushing our political views on others. What we are interested in is keeping things productive and friendly, which will allow everyone involved to further the project.

---

Some other misc stuff that has come up in discussion:

• It’s worth noting that the current CoC is a draft, we haven’t put it in place yet. As I mentioned earlier, we realize that there are problems with the contributor covenant, and our version is pretty heavily modified. I linked it earlier - why not take a read?
• Are there any specific suggestions that you have? If you could help with drafting new language that still does not allow stuff like this issue while bettering the code of conduct in your view, please feel free to suggest improved language for our community rules.
• You may say that it is a choice to be offended, but sometimes things are so obviously out of line, like calling a maintainer stupid or flaming new contributors. That type of language isn’t helpful to our project. It wastes our time, and it also discourages new contributors.
• Like all laws, there can be some abuse from those who enforce those rules. It will be important to include some balances for those who enforce laws, most likely involving the community, just to provide some oversight for maintainers with their new responsibilities when this new code of conduct takes effect.
• @mastercoms said the enforcement starting date was the end of this month, but since you bring up some good points, we can accept releasing it later so we can get it right.

I hope that helps, and I hope it wasn’t too long.

I had similar concerns, to be honest. That said, I’m happy that @mastercoms has modified it enough and have grilled her about how it would be enforced and such.

If you have any actual questions about it, ask away - that’s what we’re here for. However, as a moderate myself, I can’t say that a code of conduct is inherently bad. We do need something to refer to on expected behavior, after all.

Sorry, I haven’t gotten around to it yet. I’m sure I’ll remember soon :v

I think this covers most of what we need. It doesn’t read very well, mostly due to punctuation and lack of Markdown formatting where appropriate - can I reformat it?

Interesting idea! Just to note that there’s an issue on your server - I connect, die immediately, and are stuck in a block. Wew! Also, I can’t seem to turn my view. Browser is Vivaldi.

Most of our organic traffic comes from GitHub, and not the site. That said, I would be fine with putting that info on there - it’s a question that comes up every so often.

EDIT: I have raised this on Discord.

---

Glowstone is a small project. We are “all hands on deck”, but “all hands” is two people at the moment. There are four people on the core team - @mastercoms as the project head and lead developer, me as a sysadmin and PR guy, @momothereal as a prolific contributor and talented developer, and @kamcio96, who is currently busy with other things.

---

As it stands, any “pure” bukkit, spigot or paperspigot plugin (which is to say, one that only uses the Bukkit/Spigot/PaperSpigot API and no internals) should be compatible at this point, barring the features we don’t have implemented yet. The plugins that don’t work are not strictly Bukkit plugins, and are instead have an intimate association with the server software they’re developed for.

Some developers have decided to add specific support for Glowstone, and others have decided to write plugins with Glowstone as their primary target, but we are a small project at the moment and we don’t have the infrastructure to maintain a big database of plugins - although that is coming.

We also have the Linkstone project, which attempts to add an emulation of the net.minecraft.server package, so that plugins which rely on it will be able to work with Glowstone - but that project is currently stalled as we do not have the manpower to dedicate to it right now. Perhaps you know someone or are a developer yourself?

---

EDIT: I’m going to bed now, but feel free to drop by the Discord if you feel so inclined.

Specific issues are best left to GitHub, but I can sum up the response nicely.

These things are simply not yet implemented. Glowstone is beta-level software at the moment, and it is not yet feature-complete.

This month, the team is working on AI and mobs, so hopefully those (and related things) will be working by May.