Complaints about not having Unreleased code yet

Tremulous
132

Exploiting bugs aside (since all software is buggy), I don’t know how I could hack any of the systems in Tremulous. The only design flaw I can think of is the GUID system (not asymmetric, sent over the net unencrypted, cl_guidServerUniq is probably cryptographically flawed).

  • The client knows the states of all entities, the entityShared_t structures, whose layout is known and fixed.
  • The client knows the map.
  • All user input goes through the client.

Given the facts above, I don’t see what’s the problem with writing an aimbot that doesn’t rely on the cgame.

133

yes, the fact that the software hasn’t been formally verified, is called „commercially reasonable” security.

the software isn’t even compartmentalized:

  • can the server use its right to tell a client that the game (fs_game) has changed (in clever ways ?), and through all of that, get the client to enable downloading from the server ?1
  • is there such a thing as a map or demo file that can result in the client acting in any way other than reading from / writing to the game directories, drawing in 1 OS window, emitting an audio stream, sending network packets according to the Q3 network protocols, and acquiring mouse/keyboard input signals during focus ?

the answer for both: dafuq knows.

1 this is about recent code (based on recent ioQ3 code), where the client attempts to revert its fs_game setting to what it was before connecting to the server. 1.1.0 isn’t considered, because the answer would be simple: the server can trivially force (via a FEATURE™ of security oversight) the client to start downloading. for simplicity, let’s not consider intermediates (tjw, MG, TremFusion).

some examples of other flaws:2

  • when running server-served gamelogic on the client:
    • the server can read any content stored in the client’s game directories.
    • the server can write any content (modulo a couple of file extensions) to the game directories.
    • the server can make it difficult for the client to disconnect.
  • the data exchange between the server and the client is unencrypted and not authenticated (anything less than OTR or equivalent is a flaw).

2 again, in recent code.

i still see the opposite: u can’t write a simple program that can’t be fooled by appropriate changes in the gamelogic code. let me start by asking: what would u be looking for in the list of entityShared_t structures ?

134

Badly designed software is insecure even if formally verified.

Yes, this is flawed, but I was focusing on cheaters (ie. clients hacking the server, not the other way around), as that’s what was brought up in this thread.

Why is this a flaw? (Not counting admin impersonation, of course).

Suppose you waste a lot of time and make the server encrypt the entity states, in a way that’s impossible to reverse engineer.

The client can still deduce all the interesting information by looking at the syscalls cgame makes. Notably, the renderer has to know where all the models go.

135

technically, „formal verification” could be meant to be verifying just a property as pointless as „the program never tries to open „…/fuck_this_shit.txt”” (which would be simple if the code contains a check before every open() call), but in real field, formal verification extends to devizing a clear concept, and proving a state-of-the-art set of properties (modulo some unproven hypotheses, like „RSA is secure”).

by definition, if the software satisfies all that is asked of it, it can no longer be called buggy, especially if the specification includes all state-of-the-art properties:

  • the software doesn’t crash.
  • every call to the software eventually returns. or even: the response time is bounded.
  • the operation of the software is consistent with a simple model.

plus, the „implementational” layer of the software usually goes through a rigorization filter (eg. the above properties for each function). at this point, all run-time bugs of the classical kind have been eliminated.

  • the operation of the software is also consistent with other simple models.
  • the software fulfills a set of additional goals (including the absense of other kinds of faults).

at this point, if the specification is precise (ie., no points like „the software works PERFECT™ly”), one can be damn sure that there is no oversight in the specification, ie. maybe this software is not captured by the „all software is buggy” clause. depending on the application, the set of goals may include eg.:

  • the software is secure (eg. with respect to an actor/operator model).
  • the data transformation performed by the software is invertible (lossless compression).

otherwise, nothing else can come as close to software perfection than clean design, redundant analysis of the specification, coupled with formal verification of the implementation.

what is state-of-the-art may get broader in the future. for example, there ought to be a property like „there is an evident absence of backdoors.”, but the practice of formalizing such properties is yet to come, but one step in this direction is:

  • the software only makes calls to the system if necessary; at the very least, the set of system functions ever used is very limited.
  • teleporting through danger (eg. instakill) zones, and warping to be harder to hit, via laghacks (technically in the game module).

plus, for reference, i can name some bugs of the past, like:

btw, i should also note that the game module is also hardly sandboxed on the server, but it should be — any client should be able to upload gamelogic code, and have it run after appropiate voting, and it should be easy for the then-current clients to restore fail-safe gamelogic code on the server.

because this is crappy design. it is crappy because it is not consistent with the expectation from general users, and it is possible to do much better in this regard.

  • non-encryption effectively strips users of the reasonable possibility to enforce their right to privacy.
  • non-authentication opens a hole for user impersonations (regular, or even admin) and stealing/destruction of private or otherwise important data.

eg. the client has to decide whether „models/wtf/a_tweeping_boop.md3”, combined with a random shader, looks like a human. how easy is this ?

136

Keeping your code on your computer doesn’t make it be less FOSS.
Keeping your organization’s code on a private repo doesn’t make it be less FOSS.

Why would Tremulous devel be held in a private repo ?
1 : Tradition. It used to be in a private repo, and still is.
2 : anti-kikoo. Moderate a repository while tons of cancers open issues and asnwers infinitely is a pain, and leads you to a burn-out if you’re too much into it. A few examples

Why should Tremulous devel be public ?
1 : Accessibility to anyone. The more you get people involved the more you can get things to be done.
2 : People can learn to mod and to create new things out of it. FOSS is also a way to learn.

I think Tremulous actual “owners” focused on the community aspect that made them make it private. Telling that they’re totally wrong would certainly be hypocrite, know what I mean ?

3 Likes
137

Darklegion’s Tremulous code has been public for awhile, perhaps, at least since 1.1 was released, and probably before that. Some developers of Tremulous/mods keep their repo private in development, others keep it public (GrangerHub has kept its repo for 1.3 private for the most part until it is ready for a 1.3 release for reasons discussed in another thread, but GrangerHub has still complied with GPL in terms of availability of the code for the binaries we have released, and then some).

GrangerHub doesn’t own Tremulous as a whole, and doesn’t own the rights to the name “Tremulous”, GrangerHub’s development is independent from the original “primary” developers of Tremulous, we just decided to take on the 1.3 project because we love the game and community, and because we can since Tremulous is FOSS.

With that said each contributor does own the rights to their own contributions, it is just that if their work is derived from another work that is licensed GPL, then the new work must also be licensed as such. But that gets into copyright ownership, versus licensing.

But yes, you can say that one of the primary reasons we decided to keep our repo for Tremulous 1.3 private at this time is for consideration for the potential revival of the Tremulous community as we want our work as a whole to be of a sufficient enough quality so that upon release it has maximal opportunity to attract and retain more Tremulous players & contributors.

3 Likes
138

How can you call software “free and open” if only one developer has access to the source?

1 Like
139

There isn’t just one Tremulous source, Tremulous as a FOSS project has many versions/derivatives on many different repos, and some repos not being public at all times doesn’t make Tremulous any less of a FOSS project.

Also, unless you in someway broadcast all your coding contributions in real time to the world as you type (and I’m not just talking about having a public git repo that you might immediately push to), contributions will be private initially to various lengths of time before becoming public. I’m not saying that someone may not choose to publicly contribute in realtime, but others may choose to contribute to a FOSS project differently. The developers have a certain degree of freedom to choose how they contribute (this is part of the ‘F’ in “FOSS”).

Additionally, besides many of GrangerHub’s developers having local private repos they personally modify before pushing to any remote, GangerHub also has private repos shared among GrangerHub’s developers (so in such cases it isn’t only one developer that has access to a private repo), besides also the many public repos GrangerHub and some of its developers have.

140

Open : you have access to it. It doesn’t tell whenever you have access to it. Many games are open sourced, but not free and no one can contribute to the code neither follow the development.
SOME EXAMPLES

Free : you can contribute to it. Thought this is a weird way to do it on GrangerHub, you can contribute to it, but it is easier to do it when you asked about rights on the repo and showed you were worth being granted those rights.

Know that I’m not defending GrangerHub’s position. I’m just saying how things are.
You can only blame yourself for not being worth seeing the development c:

1 Like
141

Because it isn’t released to the public yet. Open software =/= release this incomplete software to the public now I say!

1 Like
142

I think there’s a huge disconnect between “changes not broadcasted in real time” and “secret since 2015.”

@Obani, no idea what you’re on about. FOSS is software you can use, analyze and modify however you want. Most of GrangerHub’s software doesn’t meet these criteria and simply isn’t FOSS.

It isn’t open-source yet.

1 Like
143

Yes, because it isn’t released yet. However, that doesn’t demonstrate the source code is being kept as a “secret”. We’ve been repeating this to you for about a year, yet you have been consistently ignoring this explanation and then go on to repeat the same false claim.

Either back up your claims with something material or peddle your conspiracy theories elsewhere.

1 Like
144

You completely missed the point that the time period is irrelevant to the fact that unless you broadcast your coding in realtime, ones contributions to a project will be unreleased for some time period (whether it is minutes, hours, days, weeks, months, years…), but that unreleased state does not make the project as a whole not FOSS, otherwise FOSS projects would always lose its status anytime anyone ever contributes to it not in real time.

Incorrect, first of all most of the code we work on is public (you completely ignored the fact that links have even been given in this topic and in other parts of the forums to the puiblic parts of our code), secondly you completely ignore the fact that Tremulous is a FOSS project, and not having all the code of all its versions/derivatives publicly available at all times doesn’t make Tremulous not FOSS.

145

It’s not public therefore it’s secret (a.k.a. not public, that’s all I mean by the word).

It does if you’ve never released any code in the first place (e.g. for 1.3 or the multiprotocol tremded).

You are not Tremulous.

146

Terrible logic, m8. You are using terms that, to the average user, would imply malice on the part of the developers when in reality that isn’t the case.Therefore, “Secret” would be a misnomer.

I highly suggest you refrain from using it or let everyone here know that you are acting in bad faith.

Btw according to you, every unreleased project is secret. HUEHUE

147

You are the one trying to demonize me, not the other way around, with all these inflammatory posts. The word “secret” is neutral as far as I know.

1 Like
148

http://dl.grangerhub.org/test7341/

Have fun.

Tremulous is a Free and Open Source Software project which means that anyone can contribute to that project, and anyone includes GrangerHub’s developers, and GrangerHub’s developers are exercising their freedom to contribute towards the Tremulous project.

149

I disagree. At best, I am calling you out on the basis that your claims are misleading others (using misnomers), mixed with jest. Instead of addressing the tone of my posts, I suggest you address my arguments.

Btw, if you are worried about your character being assassinated, fret not. It already happened:

teh_interrogator: why do u want the code ?

enneract: because maybe i could revive new edge
enneract: and do something interesting for a while
enneract: until the entire trem dies eventually

teh_interrogator: only that ?
teh_interrogator: for ur interest ?

enneract: yeah, what else?

Again, we’ve been repeating these same arguments to you for about a year. Perhaps now its easy to understand why there is difficulty addressing you in good faith?

150

Are you trying to prove my point for me?

But you are not Tremulous and your fork isn’t FOSS as far as any server owner or modder is concerned.

And I’ve been saying 1.3 had no future as a closed project for a year and a half. I wish I weren’t right about this.

151

The links I posted are to pk3 files that provide patches to the work in progress versions of 1.3’s cgame, ui, and “bgame”, also there are links to the current assets we are using for 1.3. Addtionally on our public github group we have the multiprotocol version of slackers which demonstrates how to “multiprotocolize” 1.1 game/cgame/ui QVMs, we also have the code to the 1.3 installer/updater there. Also a large majority of the 1.3 code is based on the latest Darklegion repo. The multiprotocol aspect of the tremded is only a small part of the code.

Again:

That is a clear misrepresentation of what a FOSS project is about. IIRC, Timbo is the sole owner of the “Tremulous” name and of the Tremulous.net website, however, while Timbo did start the project and has contributed greatly towards the game and the community, a very large majority of the contributions towards Tremulous have been by people who are not Timbo, but that doesn’t make their contributions not a part of the Tremulous project.

It is our hope (and highly likely) that upon GrangerHub’s initial release of 1.3 that the released work becomes the mainstream standard for all Tremulous projects moving forward. 1.3 includes a new client, a new tremded, new game logic, an installer, an updater, a master server, the whole works. and both the tremded and the client are backwards compatible with all old Tremulous clients/servers/QVMs. Additionally, GrangerHub supplies and is developing resources (such as this website and other infrastructures) to support the Tremulous community post 1.3 initial release.

I am unaware of any other effort outside of GrangerHub at this time that was working anywhere close on such a scope of a project for Tremulous.

Given all these facts, it is obviously false to say GrangerHub’s work on 1.3 isn’t work on Tremulous, and people who will be playing with and working on Tremulous 1.3 after the initial release aren’t going to care as long as they have fun participating with the game and the community.

That is the power of a FOSS project, members of the community continue to carry the torch and make the project greater, since those members are free to do so, there is no central power preventing the community from making contributions towards the Tremulous project as long as those members follow the terms of GPL.

3 Likes