• 2 Posts
  • 295 Comments
Joined 11 months ago
cake
Cake day: August 9th, 2023

help-circle


  • As an example, Klipper (for running 3d printers) can update its configuration file directly when doing certain automatic calibration processes. The z-offset for between a BLtouch bed sensor and the head, for example. If you were to save it, you might end up with something like this:

    [bltouch]
    z_offset: 3.020
    ...
    #*# <---------------------- SAVE_CONFIG ---------------------->
    #*# DO NOT EDIT THIS BLOCK OR BELOW. The contents are auto-generated.
    #*#
    [bltouch]
    z_offset: 2.950
    

    Thus overriding the value that had been set before, but now you have two entries for the same thing. (IIRC, Klipper does comment out the original value, as well.)

    What I’d want is an interface where you can modify in place without these silly save blocks. For example:

    let conf = get_config()
    conf.set( 'bltouch.z_offset', 2.950 )
    conf.add_comment_after( 'bltouch.z_offset', 'Automatically generated' )
    conf.save_config()
    

    Since we’re declaratively telling the library what to modify, it can maintain the AST of the original with whitespace and comments. Only the new value changes when it’s written out again, with a comment for that specific line.

    Binary config formats, like the Windows Registry, almost have to use an interface like this. It’s their one advantage over text file configs, but it doesn’t have to be. We’re just too lazy to bother.




  • What I’d like for a configuration language is a parser that can handle in-place editing while maintaining whitespace, comments, etc. That way, automatic updates don’t clobber stuff the user put there, or (alternatively) have sections of ### AUTOMATIC GENERATION DO NOT CHANGE###.

    You need a parser that handles changes on its own while maintaining an internal representation. Something like XML DOM (though not necessarily that exact API). There’s a handful out there, but they’re not widespread, and not on every language.



  • Not sure about GP, but that’s basically what we did under “SAFe” (Scaled Agile Framework). PI planning means taking most of a sprint to plan everything for the next quarter or so. It’s like a whole week of ticket refinement meetings. Or perhaps 3 days, but when you’ve had 3 days of ticket refinement meetings, it might as well be the whole work week for as much a stuff as you’re going to get done otherwise.

    It’s as horrible as you’re thinking, and after a lot of agitating, we stopped doing that shit.






  • You can get exactly the same benefit by blocking non-established/non-related connections on your firewall. NAT does nothing to help security.

    Edit: BTW–every time I see this response of “NAT can prevent external access”, I severely question the poster’s networking knowledge. Like to the level where I wonder how you manage to config a home router correctly. Or maybe it’s the way home routers present the interface that leads people to believe the two functions are intertwined when they aren’t.


  • Governments are not anyone’s issue other than other governments. If your threat model is state actors, you’re SOL either way.

    That’s a silly way to look at it. Governments can be spying on a block of people at once, or just the one person they actually care about. One is clearly preferable.

    Again, the obscurity benefit of NAT is so small that literally any cost outweighs it.

    I don’t see where you get a cost from it.

    • Firewall rules are more complicated
    • Firewall code is more complicated
    • Firewall hardware has to be beefier to handle it
    • NAT introduces more latency
    • CGNAT introduces even more latency
    • It introduces extra surface area for bugs in the firewall code. Some security related, some not. (I have one NAT firewall that doesn’t want to setup the hairpin correctly for some reason, meaning we have to do a bunch of workarounds using DNS).
    • Lots of applications have to jump through hoops to make it through NAT, such as VoIP services
    • Those hoops sometimes make things more susceptible to snooping; Vonage VoIP, for example, has to use a central server cluster to keep connections open to end users, which is the perfect point to install snooping (and this has happened)
    • . . . and that centralization makes the whole system more expensive and less reliable
    • A bunch of apps just never get built or deployed en masse because they would require direct addressing to work; stuff like a P2P instant messenger
    • Running hosted games with two people behind NAT and two people on the external network gets really complicated
    • . . . something the industry has “fixed” by having “live service” games. In other words, centralized servers.
    • TLS has a field for “Server Name Indication” (SNI) that sends the server name in plaintext. Without going far into the details, this makes it easier for the ISP to know what server you’re asking for, and it exists for reasons directly related to IPv4 sticking around because of NAT. Widespread TLS use would never have been feasible without this compromise as long as we’re stuck with IPv4.

    We forced decisions into a more centralized, less private Internet for reasons that can be traced directly to NAT.

    If you want to hide your hosts, just block non-established, non-related incoming connections at your firewall. NAT does not help anything besides extending IPv4’s life.




  • So instead we open up a bunch of other issues.

    With CGNAT, governments still spy on individual addresses when they want. Since those individual addresses now cover a whole bunch of people, they effectively spy on large groups, most of whom have nothing to do with whatever they’re investigating. At least with IPv6, it’d be targetted.

    NAT obscurity comes at a cost. Its gain is so little that even a small cost eliminates its benefit.



  • It wasn’t designed for a security purpose in the first place. So turn the question around: why does NAT make a network more secure at all?

    The answer is that it doesn’t. Firewalls work fine without NAT. Better, in fact, because NAT itself is a complication firewalls have to deal with, and complications are the enemy of security. The benefits of obfuscating hosts behind the firewall is speculative and doesn’t outweigh other benefits of end to end addressing.