• 15 Posts
  • 2.21K Comments
Joined 3 years ago
cake
Cake day: June 15th, 2023

help-circle




  • It’s fairly safe as long as you add a strong enough form of access control. For example if you put it behind a VPN, or a SSH tunnel, or require mTLS. Even a key in a custom HTTP header or Basic HTTP auth can be good enough if the key is strong enough.

    You can further decrease the probability of drive-by bots reaching a publicly exposed service by merely scanning IPs and ports if you use a reverse proxy and hide your service FQDNs and IP.

    You can do this by using TLS certs on wildcard domains rather than explicit domains, using explicit CNAMEs for the service subdomains rather than a wildcard domain, and keeping the A/AAAA records on an obfuscated subdomain rather than the base domain. If the bots can’t figure out a FQDN they’re not getting past the reverse proxy even if they find the IP and port.

    This is obfuscation not real security but it cuts down tremendously on bot hits.


  • I just can’t find any single sentence in the license text covering SaaS.

    SaaS is covered by the following fragment (emphasized by me below) which was added since version 1.1 to the last paragraph of Article 1:

    • ‘Distribution’ or ‘Communication’: any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, online or offline, copies of the Work or providing access to its essential functionalities at the disposal of any other natural or legal person.

    regarding the compatible licenses, they say the other one wins.

    If you combine the original work (licensed EUPL) with another work (licensed under weaker terms, but only applicable to one of the explicitly listed licenses), and there’s a conflict of obligations for the combined result, the terms of the lesser license prevail.

    If there’s no conflict or the other license is silent, the stronger terms prevail (EUPL).

    The original work always remains under the stronger terms (EUPL).

    Hope this clears it up.

    PS: I think maybe I understand the confusion. In the earlier comment I was talking about cross-licensing. That means making the software available under two licenses. That’s something that can only be done by the copyright holder.

    What you’re describing is not cross-licensing. If someone takes EUPL software and combines it with code under one of the other listed licenses, the distribution alone of the mixed result can be done under the terms of the other license (if the obligations conflict etc. etc.)





  • Which is better than nothing but I can’t help but see it as walking into another exclusive partnership. Also, none of those phones are out yet so I’ll believe it when I see it.

    Even if it pans out and there will be one Motorola phone supporting GrapheneOS out of the box in 2027, there’s the issue of how much it will cost (I think it’s supposed to be a “flagship”), what markets it will be available in, what the unlock process and conditions will be like etc.

    Last but not least I doubt Lenovo’s commitment to “seven years of proper updates”, which I will also believe when I see. Their track record for Android updates is notoriously poor. They claim 3-5 major Android updates for most of their models but the best I’ve actually seen them do is one update (13 to 14) – and that’s for phones released 2-3 years ago. If that’s the pace they wanna go we’ll be lucky to get two updates in those 7 years.





  • These are welcome changes but I hope they will address the elephant in the room sooner or later. They can’t go on depending on Pixels and hardware memory tagging. They need a roadmap for opening up the project to more phone models and they need it yesterday.

    They’ve drummed up some publicity with the journalist debacle so it’s a good time to use that. But people who hear about Graphene will want to have some phone choices. “Get an old Pixel” is about to age like milk.


  • Tagged VLANs would be needed regardless, because I have only one server with one physical connection and I wanted to have processes on it on 2 different networks.

    Docker is neither here nor there, you’re right it’s not needed for the solution. I was using it anyway, I know lots of selfhosters do, and it does make it easy to create an ipvlan and put an app on it.

    Docker is not the only way to achieve containerization but I do appreciate and use containerization (and virtualization). It lets the host OS stay simpler and cleaner and prevents the various apps from messing with it. It makes it easy to control each app’s environment. You can do app containers, system containers or VMs as needed. It makes it easy to back up, restore and reproduce an app and its state, independently of the host OS or any other app.

    Abstractions help… they empower you to do more. You invest some time into learning, sure, but it pays off later in time saved managing and the ability to do more complex stuff faster.

    Troubleshooting is what it is. Nothing’s perfect, you’re going to end up troubleshooting something sometime not matter what you use.



  • I did initially do it with the firewall alone. I created a “br-nvr” device, moved lan1 from br-lan to it, and used br-nvr as the device for the NVR interface and firewall zone, then selectively let my phone and the NVR app from the LAN zone access the camera ports with traffic rules.

    Everything else about the interface and zone stayed the same as they are now. That’s what’s great about the OpenWRT abstractions. I really appreciated how easy it was to get things working with the firewall zones alone, don’t get me wrong.

    The one major issue with that approach was that the NVR app is outside the NVR zone and I wanted it in there.

    • It makes broadcasting a non-issue, (I really don’t want to have to learn how to do cross-network broadcasts and I understand they’re fraught with problems anyway).
    • Better security with less complexity. A single camera can have like 3 ports that need to be made accessible, and different cameras will have different ports. Making and maintaining traffic rules for multiple cameras would rapidly turn into a nightmare.

    With the NVR app in the same isolated network as the cameras they can do whatever they want in there without needing explicit rules.

    But I couldn’t put the NVR docker container into the NVR network, because it lives on a machine on the LAN network, and you can’t have the host machine on one network and a app on it in another network, with a single physical cable… unless you use tagged VLANs.

    There are also some potential annoyances in the future if I ever want to move cables around the ports or make more complex setups, the VLAN abstraction makes things easier.


  • In this particular case it wasn’t Docker that gave me the headaches, it was OpenWRT and wrapping my head around tagged VLANs.

    Once you have the VLANs working on the router and the tagged interfaces up on the server, pointing a Docker network or an LXC at the eth0.100 interface is equally easy.

    Now, when I first got the camera I was considering adding a secondary network card to the server and plugging the camera into that, so it would be directly hardwired into the machine running the NVR. If I had done that I was given to understand that taking ownership of a physical NIC would have been much easier with LXC than with Docker.

    (We’ll never know because I couldn’t find the PCI network card.)