• 0 Posts
  • 43 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle

  • I manage a stack like this, we have dedicated hardware running a steady state of backend processing, but scale into AWS if there’s a surge in realtime processing needed and we don’t have the hardware. We also had an outage in our on prem datacenter once which was expensive for us (I assume an insurance claim was made), but scaling to AWS was almost automatic, and the impact was minimal for a full datacenter outage.

    If we wanted to optimize even more, I’m sure we could scale into Azure depending on server costs when spot pricing is higher in AWS. The moral of the story is to not get too locked into any one provider and utilize some of the abstraction layers so that AWS, Azure, etc are just targets that you can shop around for by default, without having to scramble.



  • This argument implies there’s an easy way for you to perform the reproducible builds on iOS, but it’s quite involved and requires a jailbroken iPhone. Overall this is more a limitation of apple and not signal.

    Even if you were able to perform a reproducible build of Signal on a jailbroken iPhone, there’s no way to confirm that the stock iOS Signal app will match, or has a backdoor that got added in a supply chain attack that only is delivered to non jailbroken phones. You could use a jailbroken iOS device, but then it could be lagging behind updates and be even more vulnerable from zero days.

    The real pressure here should be on Apple to provide a way to verify a build of an open source app matches what is being installed via the app store, but for some reason this is being framed as a Signal issue, which is disingenuous.


  • Not having reproducible builds is definitely weird though. Does anybody have more information on that?

    They boast this as a feature, but on the instructions for how to do this for iOS, even Telegram admits “As things stand now, you’ll need a jailbroken device, at least 1,5 hours and approximately 90GB of free space to properly set up a virtual machine for the verification process”. Browsing the steps, it’s extremely complex, and doesn’t seem like something that is very user friendly and that you’d do weekly or monthly when a new version is released.

    On the GitHub issue linked to in the body, it’s disingenuous to claim they refused to implement this, and that the technical hurdles Apple has in place make this extremely difficult which halted progress. In the community forums where the conversation was moved to, someone pointed out that even if you were to reproduce it on a jailbroken iPhone, that there’s no way to confirm that non-jailbroken iPhones aren’t receiving a version with a backdoor.

    And even if you are using a jailbroken device exclusively and can confirm the reproducibility of the iOS app, then the risk becomes the latest available jailbroken iOS could be outdated from the real versions, and you’d have other issues with not receiving timely security updates. This same issue applies to Telegram also.



  • It’s my understanding that FreeIPA can federate with Active Directory, but personally I haven’t tried that myself. As for Authentik, it looks interesting but it’s the first I’ve heard of it. I also rely on FreeIPA’s certmonger implementation, so I wonder if Authentik could replace that?

    Just to understand your use case, you have users in Active Directory where you want to manage SSH keys and be able to login via SSH to linux machines?









  • This. For example, if you have a DNS entry for your DB and the TTL is set to 1 hour, an hour before you intend to make the changes, just lower the TTL of the record to a minute. This allows all clients to be told to only cache for a minute and to do lookups every minute. Then after an hour, make the necessary changes to the record. Within a minute of the changes, the clients should all be using the new record. Once you’ve confirmed that everything is good, you can then raise TTL to 1 hour again.

    This approach does require some more planning and two or three updates to DNS, but minimizes downtime. The reason you may need to keep TTL high is if you have thousands of clients and you know the DNS won’t be updated often. Since most providers charge per thousand or million lookups, that adds up quickly when you have thousands of clients who would be doing unnecessary lookups often. Also a larger TTL would minimize the impact of a loss of DNS servers.



  • I have a coworker who always forgets TTL is a thing, and never plans ahead. On multiple occasions they’ve moved a database, updated DNS to reflect the change, and are confused why everything is broken for 10-20 minutes.

    I really wish the first time they learned, but every once and a while they come to me to troubleshoot the same issue.