Programming thread

[Kuroyuri]

Lots of valid points for Rust, but having to rely on hundreds of external packages for even small projects just doesn’t sit right with me.

With hundreds of micro dependencies another xz backdoor style fiasco becomes a lot more plausible, or even more likely: troons randomly destroying chains of dependencies just because.

 

[Creative Username]

Lots of valid points for Rust, but having to rely on hundreds of external packages for even small projects just doesn’t sit right with me.

With hundreds of micro dependencies another xz backdoor style fiasco becomes a lot more plausible, or even more likely: troons randomly destroying chains of dependencies just because.

i would like rust if it was cc but instead of implementing the gay portable assembler known as c it implemented something with decent lifetime checking
unfortunately, it's trying to be the nodejs of system programming languages and pretty much everybody from that part of the field hates that

 

[stares at error messages]

I've been looking at Google's YouTube API. It uses OAuth2. You have to create a registration and then use it in your app, web site, or whatever. The whole point of using OAuth is so users can sign-in and use the Google API under their account instead of the developer's account. The end user is responsible for not issuing too many requests and using up there allowance of API requests for the day. If it were all though the developer's account the number of all the users' requests could get expensive to provide; it'd use up the free requests and the volume would cause the developer to be out a lot of money to support all the users. So far OAuth2 seems intentionally broken. You have a App ID and a App Secret. The secret you are not supposed to share publicly and not hard coded into your app. However, you need this value to keep the app working after the first logs-in with OAuth. After the OAuth handshake, you are left with an hour token and a refresh token. If the hour token has expired you can just get another with the same refresh token. So what you are really getting out of the handshake is a refresh token that then allow the app to operate under the end user's account going forward. The problem is, where is the developer supposed to store the App Secret if you need it to use the refresh token every time? It has to be either hard coded or hosted on some server somewhere. It's like Google is implying that every app that uses their API is some God awful TenCent always-on-line verification server thin client that is only pulling-in requests from different servers, so one more "security" request makes no difference. This is really poorly designed. I don't know why they have an App Secret that isn't unique for each user, that way it's on the user if they are doing anything funny (stealing the App ID to make a bunch of requests like spoofing a user agent) and not the developer's responsibility to engineer another useless HTTP request just to get the App Secret on the user's system. Really the whole idea of an App Secrete is redundant when you consider that the API is being called in the end user's name (on their account) so it should represent no difference to Google who or what is making those authorised requests. The App ID is basically a User Agent field, so it's technically not necessary. (Yes I know Cloudflare and other services check for it, but the server can ignore it and work all the same.) The App ID user agent and App Secret are both free things you can generate or re-generate at any time. They are essentially throw-away, so long as all your users upgrade to the newly generated values. All the authority in OAuth comes from the user logging into their account anyway, so there is no reason to try to keep the app secure if it's just a different user agent for making requests to Google on the account. It's not like there is a significant difference between an API request from a 3rd party app and an internal API request from a Google web site. As far as I can tell Google's OAuth is broken. Every kind of app you can make to use it needs the same stupid App Secret. And the App Secret is basically like having a bifurcated user agent because you need both the secret and the ID to do anything.

I'd also like to add Google's documentation web sites use too much CPU just to display some text. I can hear may fans spin up whenever I'm on that tab. It's absolutely inexcusable to have this poor performance for a literal book. Also their API explorer demo tester thing is broken. Really looks like you're not having any trouble keeping the lights on there, Google.

 

[y a t s]

You have a App ID and a App Secret

As like in basically every other API.

The problem is, where is the developer supposed to store the App Secret if you need it to use the refresh token every time?

Isn't this what a .env file is for?

The App ID user agent and App Secret are both free things you can generate or re-generate at any time.

That's the point. The broader point is that only you know the values and no one else can issue auth tokens for your specific app.

 

[Rango Dango]

I like using snake_case for variables and camelCase for functions

 

[y a t s]

I like using snake_case for variables and camelCase for functions

I won't reignite any flame wars, but please, for the love of God, pick one and be consistent.

 

[analrapist]

pick one and be consistent

char* sz_userName_tmp=NULL;

 

[Rango Dango]

I won't reignite any flame wars, but please, for the love of God, pick one and be consistent.

I am consistent
variables - snake_case
functions - camelCase
types - PascalCase
#define/constexpr/enum constants - SCREAMING_CASE
files - no case at all fuck you
it basically allows you to differentiate things at a glance like syntax highlihgting, except symbols instead of colors

 

[analrapist]

but this is not official way of doing, and they gonna gimp local users more and more with time.

Bought a Mele Quieter 4C for a friend of mine recently. Set it up personally. As it shipped, the out-of-box-experience defaulted to Local User, not Microsoft Account. I was not asked to sign into Microsoft AT ALL. I entered "User" for the username, no password, everything just works. The notion that the Microsoft Password approach is "the only official way" seems to be wrong by this data point. IDK how many other vendors are doing this though. Mele is very end-user focused, and you pay a premium for it.

 

[y a t s]

I am consistent
variables - snake_case
functions - camelCase
types - PascalCase
#define/constexpr/enum constants - SCREAMING_CASE
files - no case at all fuck you
it basically allows you to differentiate things at a glance like syntax highlihgting, except symbols instead of colors

I fully understand and agree with consts, types, and files, but I fail to see how this is useful for distinguishing functions and typical vars. A function call has (args...) at the end. If you're passing named functions as arguments enough for this to be a consideration, I feel like there's a better way to achieve whatever you're doing.

 

[GNU Abyss]

Wrote a solver for Kiwiflare in Python and found that, outside of JS workers, there is no need to pay attention to patience limits as they're in the range of 200000+ ms, whereas a solution on the standard difficulty of 16 takes about .14ms on my fairly weak machine.

Poking around the original, minified source code and licenses attached also led me to believe that the worker file is the entirety of the crypto-js npm package (therefore every algorithm it supports outside of SHA-256), minified and compressed, with a little bit of custom code attached. Given how even browsers that are considered old in $current_year have built-in facilities for simple crypto, saving about 50kB on each challenge solved would be pretty sweet. I'm pretty sure even Pale Moon has support for this, considering it's a fork of Firefox 52 originally. Maybe it's time to finally learn the NodeJS beast to make a leaner prototype.

 

[Rango Dango]

I fully understand and agree with consts, types, and files, but I fail to see how this is useful for distinguishing functions and typical vars. A function call has (args...) at the end. If you're passing named functions as arguments enough for this to be a consideration, I feel like there's a better way to achieve whatever you're doing.

i was talking about stuff like FunctionOne(FunctionTwo(a_variable)), which does make a difference when just skimming thru, and is otherwise more consistent than "everything has its own convention except functions and variables" and idk feels more organized as well
also, yes, i would write it like this

int fooBar(int* baz);
typedef int (*SomeFunc)(int*)
SomeFunc some_func = &fooBar;

 

[Creative Username]

the lisp shill squad would like to inform the unwashed masses of ignorant statementniggers that the only true way to name variables is with kebab-case and everything else is absolutely retarded
thank you for your time and have a very parenthesized day

 

[Lard Shart]

I like using snake_case for variables and camelCase for functions

I do the same, except with PascalCase instead of camelCase.
I would use PascalCase everywhere, but it just feels off on variables and fields.
It's apparently also what Terry used for TempleOS, here's a random code sample:

Spoiler: Random TempleOS code

Bool SuggestSpelling(U8 *word)
{
  U8 *dict=acd.word_lst,
    *pf=SuggestMatchForm(word),
    *wf;
  I64 len=StrLen(pf),
    num_cols=Fs->win_width/16,
    col=0;
  if (len)
    while (*dict) {
      wf=SuggestMatchForm(dict+1);
      if (!StrNCmp(pf,wf,len)) {
    "%16s",dict+1;
    if (++col>=num_cols) {
      col=0;
      '\n';
    }
      }
      Free(wf);
      dict+=StrLen(dict+1)+4;
    }
  Free(pf);
  '\n';
  return ToBool(len);
}

 

[Rango Dango]

I do the same, except with PascalCase instead of camelCase.
I would use PascalCase everywhere, but it just feels off on variables and fields.
It's apparently also what Terry used for TempleOS, here's a random code sample:

Spoiler: Random TempleOS code

Bool SuggestSpelling(U8 *word)
{
  U8 *dict=acd.word_lst,
    *pf=SuggestMatchForm(word),
    *wf;
  I64 len=StrLen(pf),
    num_cols=Fs->win_width/16,
    col=0;
  if (len)
    while (*dict) {
      wf=SuggestMatchForm(dict+1);
      if (!StrNCmp(pf,wf,len)) {
    "%16s",dict+1;
    if (++col>=num_cols) {
      col=0;
      '\n';
    }
      }
      Free(wf);
      dict+=StrLen(dict+1)+4;
    }
  Free(pf);
  '\n';
  return ToBool(len);
}

I don't like PascalCase for anything other than types, because the fucking TreeSitter syntax highlighter for C/C++ colors PascalCase functions as constructors, so for example, if I were to use raylib, that syntax highlighter would color idk BeginDrawing() as if it was a constructor (functions use a different color to constructors)

 

[y a t s]

Wrote a solver for Kiwiflare

Me too.

and found that, outside of JS workers, there is no need to pay attention to patience limits as they're in the range of 200000+ ms, whereas a solution on the standard difficulty of 16 takes about .14ms on my fairly weak machine.

As I'm sure you figured out, patience is a value given in minutes (there is a minor catch here that idk if I should mention openly). My only note here is that this works to mitigate DDoS attacks because the underpowered IoT devices that comprise botnets can't produce solutions fast enough, hence creating a big bottleneck. My point being that there are still plenty weak machines out there that the patience value becomes a problem for. Or, at the very least, there are devices that are slow enough where it's arguably worth it to pay attention to the patience value. It really says a lot that the 16 bit standard difficulty setting works as well as it does.

Poking around the original, minified source code and licenses attached also led me to believe that the worker file is the entirety of the crypto-js npm package (therefore every algorithm it supports outside of SHA-256), minified and compressed, with a little bit of custom code attached. Given how even browsers that are considered old in $current_year have built-in facilities for simple crypto, saving about 50kB on each challenge solved would be pretty sweet. I'm pretty sure even Pale Moon has support for this, considering it's a fork of Firefox 52 originally. Maybe it's time to finally learn the NodeJS beast to make a leaner prototype.

You're probably right, though the larger minified source file does have the perhaps unintended side effect of being a bigger pain in the ass to reverse engineer. Enough to scare away the lazier trannies, at least.
And, to immediately contradict myself, I'll conclude with the obligatory "security by obscurity is not true security".

 

[stares at error messages]

Isn't this what a .env file is for?

'.env' files are not secure. The Google API documentation says the App Secret has to be kept 'secure'. If some one snooping around files on their computer can discover it, then it's not secure. Shipping a file with the program with the values is no better than hard coding the values. They are still on the user's machine, and therefore at the mercy of the user or whatever malware the user has on their system. If the values are physically on the user's system unencrypted, then they are not secure. If the user has the decryption key and the encrypted data at the same time on their system, then the data is not secure.

This is not about keeping the values out of Git. This is about not letting the user see the value. Which is not practical for how the API is meant to be used assuming your not running an app that always dial home for every action. For containers, I would argue that people can just inspect the container and get the '.evn' values if you are distributing the container publicly. If the container is running on the server and it is not publicly distributed, then maybe that's secure. I mentioned this is my post:

It has to be either hard coded or hosted on some server somewhere. It's like Google is implying that every app that uses their API is some God awful TenCent always-on-line verification server thin client that is only pulling-in requests from different servers, so one more "security" request makes no difference.

To reiterate, security doesn't mean not in Git repository or not returned when running string on a binary or can't be found in source code. Secure means that it is difficult or impossible for the wrong party to have access to the information. If an end user can get the information because it's part of the files that get installed on the user's system or in the containers they download off docker hub then it is not secure. It is not difficult to open a hidden file on the user's system. My thesis is very simple. OAuth replaces API Keys with a user agent and a trusted user account, so it's not an issue that the identity of the App is misused. It's all on the trusted account. So it's wrong for Google to call a bifurcated user agent something that is meant to be stored securely when many apps that are not always dialling home can't do that. The risk that is trying to be mitigated with the security is also negligible. It’s wrong to recommend keeping a user agent secure in the first place, where traditionally user agents are never secured in this way. Other OAuth providers don’t even use a App Secret. Google is just adding addition complexity and jargon words needlessly. It’s like Dave Plummer designed their API.

---

TLDR:

Are you fucking kidding me?

https://blog.openreplay.com/handling-env-files-in-latest-node/

node --env-file=.env index.js

That is not secure.

 

[y a t s]

If some one snooping around files on their computer can discover it, then it's not secure.

If a snooping someone has that level of access to your machine, you have a lot bigger issues than your app secret getting leaked.

And your app secret isn't something end-users have to concern themselves with. They get the ephemeral oauth tokens through your server that makes API calls using your app secret. Basic API stuff.

 

[Verpa Teutonica Ingens]

If a snooping someone has that level of access to your machine, you have a lot bigger issues than your app secret getting leaked.

I'm pretty sure he's referring to desktop software, not webapp shitware. Users of desktop programs merely need to snoop around their own machines, not the developer's machines, to find things like the app tokens that are needed for OAuth2.

I'm sure there's some authentication flow to accommodate desktop programs, as a generous consolation from our benevolent Google benefactors. I'm also sure that it's needlessly complicated, on a similar level as Java enterprise jeetware.

 

[GhastlyGhost]

I'm pretty sure he's referring to desktop software, not webapp shitware. Users of desktop programs merely need to snoop around their own machines, not the developer's machines, to find things like the app tokens that are needed for OAuth2.

I'm sure there's some authentication flow to accommodate desktop programs, as a generous consolation from our benevolent Google benefactors. I'm also sure that it's needlessly complicated, on a similar level as Java enterprise jeetware.

And if you use a third party web api and ship keys to it to your users, you're a mouth breathing retard.