I don't see the similarity. The Ceylon feature I find awkard is that class definitions have two parts (initializer/declaration) with different semantics, without explicit demarcation.
In the example above, this code:
class Point() {
Float x => y;
Float y => x;
}
is fine, because both declarations are parsed as being in the declaration section. However, when you add another line after that:
class Point() {
Float x => y; //compiler error: y is not referenceable
Float y => x;
Float->Float xy = x->y;
}
The original two declarations are now part of the initializer section, because the third line is a statement that is not allowed in the declaration section. This changes the semantics of the first two lines.
FTR, the whole declaration section vs initialization section stuff really boils down to this:
You can't declare mutually-recursive methods before
initialization logic in the body of a class. You have to
declare them _after_ the fields of the class are fully
initialized.
That's not so hard to understand.
To see why it's like this, you need to consider :
- Unlike most OO languages Ceylon statically _guarantees_ that a field of an object is initialized before it is accessed. (If we didn't, then we would have to have something conceptually equivalent to a NullPointerException when you access a field before initialization.)
- We've always hated the amazingly repeaty syntax of constructors in C++/C#/Java.
What I mean is, in Java I have to write stuff like:
class Point {
final float x;
final float y;
Point(float x, float y) {
this.x = x;
this.y = y;
}
}
In Ceylon, it would be:
class Point(Float x, Float y) {}
And even with all that verbosity in the Java version, I _still_ don't get a static guarantee that `x` and `y` are initialized before they are used by a method. This code prints `0.0`:
class Point {
final float x;
final float y;
Point(float x, float y) {
fun();
this.x = x;
this.y = y;
}
void fun() { System.out.println(x); }
public static final void main(String[] args) {
new Point(1.0f,2.0f);
}
}
So Ceylon wants to solve _both_ these problems: eliminate the verbosity, and provide the static checking for initialization. Now, this is an _almost_ completely transparent process. I almost never find myself thinking about declaration section vs initialization section. I just write classes so that fields are initialized before the methods that use them are declared. Which is basically super-intuitive. In >95% of classes that's all you need to know. Very rarely, I mix this up, and the compiler complains and I need to move a member up or down. Which takes seconds to fix. Very, very rarely, I have a class with some kind of self-recursive initialization logic and then only in that case do I need to start holding the mental model of declaration-vs-initialization sections in my head. In practice, I think I've only run into this situation _once_, and it took me a few minutes to restructure the code. (FTR, it was `ArrayList` in `ceylon.collection`.)
This is incredibly dangerous. Because it's http, it can be Man-In-The-Middle'd, so you're basically executing arbitrary commands on your computer. (See: php function exec()). Also, even if it's non TLS/SSL, you're putting a lot of trust in Rainloop not being hacked or malicious.
If your network is Man-In-The-Middle'd you are probably fucked in more than one way, and a backdoored php install script is the least thing you should worry about.
It's no different to just download an installer and double click it.
Providing verification methods in alternative channels is essential if you need make sure everything is clean.
> If your network is Man-In-The-Middle'd you are probably
> fucked in more than one way, and a backdoored php install
> script is the least thing you should worry about.
Connecting to MITM'd networks is extremely common, and millions of people (even technical people) intentionally do so every day. If you've ever used a free Wifi hotspot with one of those click-through use agreements, you've used a MITM'd connection.
The only reasonable security stance towards the security of your local internet connection is to assume that it's got something malicious on the other end of it. That's why using HTTPS is so important.
> It's no different to just download an installer and
> double click it.
Most people install applications via app stores nowadays, which verify signatures on the application before installing. HTTPS is widely used in non-app-store distribution systems.
With a normal download, you're likely to wait until it's done before invoking it.
With a pipe-to-interpreter, the interpreter (php/sh/etc..) is possibly interpreting code as it receives in batches of (line/chunk/etc.).
A danger therein lies in the possibility of an unexpected pipe interruption (network, or software) feeding something that's technically runnable by the interpreter but logically broken.
Imagine coming down the pipe is "rm -rf /tmp/installer-data" but curl uses too much memory and the linux OOM killer nukes it and sh receives only "rm -rf /"
In general, when I've seen this technique used in Ruby (RVM?, back in the day) and/or PHP (Composer recommends a similiar Curl install technique, but composer.phar is an digest-archive of sorts ....) the installer code tends to be about a paragraph worth of text.
All in all I understand your point. But your contrived example of rm -rf seems a little too contrived. In this case we're were talking about PHP code ... the chunked-piped code would still need to be valid PHP of what "rm -rf /" is not as it's missing important tokens to denote valid php expression(s).
It seems like it would be equally worrisome to worry about Brownian Motion flipping a bit in memory and catastrophically affecting my program execution -- possible but unlikely.
FWIW I used the word "pipe" very loosely to mean everything to the left of the interpreter. That means the unix pipe itself, but also the curl program, OS feeding it, network it's on, remote server feeding it, etc.
There are several scenarios where that logical pipe can fail. It doesn't have to happen cleanly on a 64-kb unix pipe buffer boundary. Some examples may include someone bouncing an office router and all TCP connection states getting reset, a neighbor microwaving lunch and WiFi radios croaking, a carrier having networking issues and connections timing out, the remote server restarting the web server after a software upgrade, etc..
I'm not sure curl (even with -s) will gracefully handle all of these cases defensively (doubly-so if the HTTP server was sending back chunked-encoding without explicitly specifying a Content-Length)
At the end of the day, having not even considered what an active attacker could do but just what could naturally blow-up a small percentage of the time I'm inclined to say "that's bad, mmkay?" and try to persuade developers not to push that as a safe installation method. Even if they've triple-checked that the code they've written + interpreter can not possibly do harm in that case, the signal we should be sending (primarily to end-users) is that this may be an unsafe operation.
> ... OOM killer nukes it and sh receives only "rm -rf /"
If curl was SIGKILLed, wouldn't that result in a "broken pipe", therefore causing the shell to abort? The only way the "rm -rf /" would be executed would be if the pipe shut down cleanly and the shell saw an EOF (since obviously there would not be a newline in the scenario you described).
>>Also, even if it's non TLS/SSL, you're putting a lot of trust in Rainloop not being hacked or malicious.
I'm assuming that "non" shouldn't be there, so... I don't know how I feel about the whole curl/wget [url] | [interpreter] trend. In theory, it shouldn't really be that different from the days of downloading "setup.exe" and running it.
If for some reason you don't trust Rainloop then you shouldn't install anything of theirs no matter what the delivery method is.
> Also, even if it's [on] TLS/SSL, you're putting a lot of trust in Rainloop not being hacked or malicious.
It seems like no matter how you install the software, you likely have to put at least that level of trust in them. Unless you run it in its own VM or other sandbox, of course.
For a long time the officially documented way to install GNOME was to lynx -dump http://go.gnome.org and pipe it to a root shell. Looks like the industry hasn't learned much in twenty years.
Couldn't you say the same thing about downloading and running any installer from the internet? There is nothing special about PHP that makes this insecure, the exact same attack you describe could be done when you are downloading a Windows installer executable from a browser and double clicking it.
>There is nothing special about PHP that makes this insecure
He didn't say it was because of PHP, he said it was because of http (i.e., because it's not over SSL).
> the exact same attack you describe could be done when you are downloading a Windows installer executable from a browser and double clicking it
Exactly, which is why people who are security conscious never simply execute a Windows installer downloaded from the browser (or wget, for that matter). At a minimum, one checks the file hashes. Ideally, one confirms that the executable has been properly signed and not tampered with (by right-clicking the file, clicking 'properties' and looking at the 'signature' tab, or else manually checking if it's been GPG signed).
It's not just that this can emulate the second. Sometimes VSCO Film is the second, or at least the foundation for the second. It's kind of swept the modern photography world by storm.
That said, to the grand-parent poster: I realize that it isn't the same thing as described in the paper! However, it is available now, and I was using phrases such as "not entirely unlike" which shouldn't exactly inspire a sense of precise equivalence...
If you look on the left, the learning plan shows that it would take 22 hours to complete from the bottom up. Logistic regression page just assumes you know all prior knowledge.
