Live data from Hacker News

I'm switching to Python and actually liking it

cesarsotovalero.net

691–700 of 718 posts

Re: I'm switching to Python and actually liking it

#691

Earlier quoted context omitted.

As a mathy person myself, I find the OOP leaning difficult to think about. Better equational reasoning, better lambdas, fewer side effects to worry about, avoiding mutation so that I can define something and still know what it is later during runtime, those are what help me think clearly. To me OOP is about the furthest paradigm from math that I’ve used.

Its quite easy to avoid OOP though.

The only reason I would use Python is for its specialized AI/ML frameworks, and unfortunately those force you to go with OOP.

Re: I'm switching to Python and actually liking it

#692

Earlier quoted context omitted.

As a mathy person myself, I find the OOP leaning difficult to think about. Better equational reasoning, better lambdas, fewer side effects to worry about, avoiding mutation so that I can define something and still know what it is later during runtime, those are what help me think clearly. To me OOP is about the furthest paradigm from math that I’ve used.

Well it’s not about math. Stick to lines of code, functions and modules for that. Use it for abstract data types, frameworks and modeling.

You’re right, it’s not good for math, but unfortunately we have the legacy of AI / ML being entrenched into that ecosystem, with no clear leaders as alternatives.

Re: I'm switching to Python and actually liking it

#693
post #666

"And guess what's the de facto programming language for AI? Yep, that sneaky one." Is this referring at all to to PyTorch. If not, any guesses what the author has in mind "Not only because the syntax is more human-friendly, but also because the Python interpreter is natively integrated in all Unix distros." Is this referring to GNU/Linux. UNIX (UNIX-like) includes more than Linux; some UNIX distributions do not inclu…

>I do not use Python for this; I use a 19-line shell script (ash not bash), its startup time is faster Ash doesn't do web requests unless you've implemented HTTP in ash. You're back to using 3rd party dependencies that aren't installed on all systems

For this script I have "implemented HTTP" using printf, an ash builtin.

The TCP networking is done with orginal netcat reading the HTTP from a pipe.

The TLS is handled by a TLS forward proxy listening on the loopback.

The orginal netcat and other TCP clients I use, like tcpclient from djb's ucspi or tcploop from haproxy, are not part of the NetBSD base system but are easily added when I compile the OS. For Linux I use a custom distribution I make myself, without LFS. Busybox has ash and nc together in the same binary.

These TCP client programs are stationary targets, they will work reliably year after year, and small enough that I can store and compile them quickly even on computers with modest resources. Python is constantly evolving, a moving target, and much larger.

I wrote a utility in C89 that "implements HTTP" called yy025. This is produced using GCC, specifically flex, which is intsalled on all systems I use. flex is part of the NetBSD toolchain. It's a requirement for compiling the OS. It's a requirement for building many GNU userland utilities. It's even a listed requirement when building the Linux kernel.

yy025 is what I normally use in shell scripts when I need to generate HTTP. It reads URLs on stdin and outputs customised HTTP to stdout. There is no "third party dependency" for HTTP. This is a "first party" program. I wrote it.

But this script to fetch YouTube metadata doesn't use yy025. It's just some printf statements.

Re: I'm switching to Python and actually liking it

#694
post #590

Earlier quoted context omitted.

> Oddly enough It's not that odd, since it's the only situation where you cannot keep it bounded, unless you enjoy having variables that may or may not be defined (Heisenberg variable?), depending on whether the exception has been raised or not? Compare with the if statement, where the variable in the expression being tested will necessarily be defined.

Are you saying that this should result in a name error? if : x = 5 print(x) #

In any sane language it would, yes.

Re: I'm switching to Python and actually liking it

#695
post #429

Earlier quoted context omitted.

You don't generally want API keys accidentally recorded into someone's bash history.

What exactly is your threat model, where the attacker can read ~/.bash_history but can't execute (or capture output from) /usr/bin/env?

The threat model is that history is persistent while the environment isn't. That said, whenever possible you should handle secrets using file descriptors as opposed to environment variables.

Re: I'm switching to Python and actually liking it

#696

Earlier quoted context omitted.

For this example, don't just command line arguments. There's an API key there, you don't want an API key visible in your cmdline.

Then how would you SET the API key in the first place? :) The argument doesn't make any sense at all.

Using read or an equivalent, presumably. Just because you don't know why a practice is recommended against doesn't mean that there isn't a good alternative.

Re: I'm switching to Python and actually liking it

#697

Earlier quoted context omitted.

Typer has a great feature that lets you optionally accept argument and flag values from environment variables by providing the environment variable name: https://typer.tiangolo.com/tutorial/arguments/envvar/ It's especially nice for secrets. Best of both worlds :)

No, that's an anti-feature. :) Sibling comments here claim that command line arguments "leak" whereas environment variables does not. It's plain wrong. An attacker with access to arbitrary processes' cmdline surely also has access to their environ. Store secrets in files, not in the environment. Now you can easily change secret by pointing the --secret-file parameter to a different file. The only reason people use BL…

This is bad advice. Please don't make claims about security if you're making it up as you go.

Environment variables are substantially more secure than plain text files because they are not persistent. There are utilities for entering secrets into them without leaking them into your shell history.

That said, you generally should not use an environment variable either. You should use a secure temporary file created by your shell and pass the associated file descriptor. Most shells make such functionality available but the details differ (ie there is no fully portable approach AFAIK).

The other situation that sometimes comes up is that you are okay having the secret on disk in plain text but you don't want it inadvertently commited to a repository. In those cases it makes sense to either do as you suggested and have a dedicated file, or alternatively to set an environment variable from ~/.bashrc or similar.

Re: I'm switching to Python and actually liking it

#698

Earlier quoted context omitted.

In some .profile or .envrc or what you'd call such a file, I suppose.

And you expect someone will be able to read your bash_history, but not your .profile?

Fair, I wasn't thinking about the details of how someone would lift out the bash history.

Re: I'm switching to Python and actually liking it

#699
post #666

Earlier quoted context omitted.

>I do not use Python for this; I use a 19-line shell script (ash not bash), its startup time is faster Ash doesn't do web requests unless you've implemented HTTP in ash. You're back to using 3rd party dependencies that aren't installed on all systems

For this script I have "implemented HTTP" using printf, an ash builtin. The TCP networking is done with orginal netcat reading the HTTP from a pipe. The TLS is handled by a TLS forward proxy listening on the loopback. The orginal netcat and other TCP clients I use, like tcpclient from djb's ucspi or tcploop from haproxy, are not part of the NetBSD base system but are easily added when I compile the OS. For Linux I us…

In more recent times, NetBSD has added OpenBSD's version of nc to the base system.

One could thus argue that there is a TCP client "installed on every system".

For me, what is more important is an installed copy of GCC. I have yet to use a UNIX-like system that did not have the needed networking functions to create a basic TCP client.

Re: I'm switching to Python and actually liking it

#700

Earlier quoted context omitted.

No, that's an anti-feature. :) Sibling comments here claim that command line arguments "leak" whereas environment variables does not. It's plain wrong. An attacker with access to arbitrary processes' cmdline surely also has access to their environ. Store secrets in files, not in the environment. Now you can easily change secret by pointing the --secret-file parameter to a different file. The only reason people use BL…

This is bad advice. Please don't make claims about security if you're making it up as you go. Environment variables are substantially more secure than plain text files because they are not persistent. There are utilities for entering secrets into them without leaking them into your shell history. That said, you generally should not use an environment variable either. You should use a secure temporary file created by…

Good luck storing your private keys in environment variables!
Post reply on HN