Preface

Software security is one of those subjects that often gets overlooked, both in academia and in professional projects, unless you're specifically working with some existing security-related element (e.g. you're taking a course on security basics, or updating your password hashing algorithm). As a result, we frequently see stories of rather catastrophic data leaks from otherwise reputable businesses, leaks which should have been entirely preventable with even the most basic of safeguards in place.

With that in mind, I thought I would switch things up and discuss something security-related this time.

Background

It's commonplace for complex software systems to avoid unnecessarily large expenses, especially in terms of technical debt and the capital involved in the initial development costs of building entire systems for e.g. geolocation or financial transactions. Instead of reinventing the wheel and effectively building a parallel business, we instead integrate with existing third-party systems, typically by using an API.

The problem, however, is that sometimes these third-party systems process requests over a long period of time, potentially on the order of minutes, hours, days, or even longer. If, for example, you have users who want to purchase something using your online platform, then it's not a particularly good idea to having potentially thousands of open connections to that third-party system all sitting there waiting multiple business days for funds to clear. That would just be stupid. So, how do we handle this in a way that isn't incredibly stupid?

There are two commonly accepted methods to avoid having to wait around:

1. We can periodically contact the third-party system and ask for the current status of a request, or
2. We can give the third-party system a way to contact us and let us know when they're finished with a request.

Both of these methods work, but obviously there will be a potentially significant delay in #1 between when a request finishes and when we know that it has finished (with a maximum delay of the wait time between status updates), whereas in #2 that delay is practically non-existent. Using #1 is also incredibly inefficient due to the number of wasted status update requests, whereas #2 allows us to avoid that kind of waste. Clearly #2 seems like the ideal option.

Method #2 is what we call a webhook.

May I see your ID?

The problem with webhooks is that when you're implementing one, it's far too easy to forget that you need to restrict access to it. After all, that third-party system isn't a user, right? They're not a human. They can't just give us a username and password like we want them to. They don't understand the specific requirements for our individual, custom-designed system.

But what happens if some malicious actor figures out what the webhook endpoint is? Let's say that all we do is log webhook requests somewhere in a non-capped file or database table/collection. Barring all other possible attack vectors, we suddenly find ourselves susceptible to that malicious actor sending us thousands, possibly millions of fraudulent data payloads in a small amount of time thanks to a botnet, and now our server's I/O utilization is spiking and the entire system is grinding to a halt--we're experiencing a DDoS!

We don't want just anyone to be able to talk to our webhook. We want to make sure that anyone who does is verified and trusted. But since we can't require a username and password, since we can't guarantee that the third-party system will even know how to make use of them, what can we do?

The answer is to use some form of token-based authentication--we generate a unique token, kind of like an ID card, and we attach it to our webhook endpoint (e.g. https://example.com/my_webhook/{unique_token}). We can then check that token for validity every time someone touches our webhook, ensuring that only someone we trust can get in.

Class is in Session

Just as there are two commonly accepted models for how to handle receiving updates from third-party systems, there are also two common models for how to assign a webhook to those systems:

1. Hard-coding the webhook in your account settings, or
2. Passing a webhook as part of request payload.

Model #1 is, in my experience, the most common of the two. In this model, our authentication token is typically directly linked to some user or user-like object in our system. This token is intended to be persisted and reused indefinitely, only scrapped in the event of a breach or a termination of integration with the service that uses it. Unfortunately, if the token is present within the URL, it's possible for your token to be viewed in plaintext in your logs.

In model #2, it's perfectly feasible to mirror the behavior of model #1 by simply passing the same webhook endpoint with the same token in every new request; however, there is a far better solution. We can, instead, generate a brand new token for each new request to the third-party system, and each new token can be associated with the request itself on our own system. Rather than only validating the token itself, we then validate that the token and the request it's supposed to be associated with are both valid. This ensures that even in the event of a breach, a leaked authentication token's extent of damage is limited only to the domain of the request it's associated with! In addition, we can automatically expire these tokens after receiving a certain number of requests, ensuring that a DDoS using a single valid token and request payload isn't possible. As with model #1, however, we still run into problems of token exposure if the token is present in the URL.

Model #2 treats each individual authentication token not as a session for an entire third-party system, but as a session for a single request on that system. These per-request session tokens require greater effort to implement, but are inherently safer due to the increased granularity of our authentication and our flexibility in allowing ourselves to expire the tokens at will.

Final Thoughts

Security is hard. Even with per-request session tokens, webhooks still aren't as secure as we might like them to be. Some systems allow us to define tokens that will be inserted into the request payload, but more often than not you'll find that only a webhook URL is possible to specify. Ideally we would stuff those tokens right into the POST request payload for all of our third-party systems so they would never be so easily exposed in plaintext in log files, but legacy systems tend to be slow to catch up and newer systems often don't have developers with the security background to consider it.

Still, as far as securing webhooks goes, having some sort of cryptographically secure authentication token is far better than leaving the door wide open for any script kiddie having a bad day to waltz right in and set the whole place on fire. If you're integrating with any third-party system, your job isn't to make it impossible for them to get their hands on a key, but to make it really difficult and to make sure you don't leave any gasoline lying around in case they do.

I was using Antergos for like 15 days and I really loved it! Not Antergos but Arch, I like how simple everything is in arch. Before installing antergos I tried to install arch on vm but failed. so i installed antergos with i3wm. somewhere i wanted to install vanilla arch.

Initially I was referring to the wiki with elinks and doing it carefully but failed. my setup was going to be arch + grub + luks, for some reason grub didn't show up while booting. i also encountered other error which made grub-mkconfig to hang. later i decided to drop luks so arch + grub, but again same error.

i've used debian family distros for a long time and grub was the most used bootloader so i wanted to install that. next i looked for a guide online and followed another guide which had same commands as arch wiki. again that failed.

after some more searching i found archfi, so basically it is a script that will ask me questions and install everything. again that grub thing failed so i went with systemd for the second time with this script. & voila!

later i used archdi to setup lightdm-gtk-greeter and installed i3wm.

i didn't install it myself but i am happy with my arch and probably someday would do it myself.

btw, i use arch

I wish I had a dollar for every time I heard a manager complain, “The HR department included ‘must have college degree’ in the job req even though I don’t care” or “They asked for 5 years of experience in a technology that’s only been around for 3” or “I have no idea why they rejected this candidate without even contacting me.”

Still, in many cases you don’t have a choice. If you want to hire someone, you need to deal with HR, at least to a small degree – especially if you work in a big company.

So I’m writing a feature story for technology managers, collecting real-world advice from people who learned their lessons the hard way. Here’s the questions I’d like you to answer:

• Tell me about a frustration you had with the HR department (in regard to hiring). That is, tell me a personal story of HR-gone-wrong. Because we all love schadenfreude, and that gives me an emotional example with which to begin.
• Let’s say you have a new opening in your department. In what ways do you involve HR? (That could be anything from, “give them general guidelines and let them choose the best candidates for me to interview” to “I do the search myself, and use HR only for on-boarding.”) What makes you choose that path? How much choice do you have in the matter?
• What weaknesses have you discovered in your HR department’s ability to serve the needs of a tech-focused department?
• What have you done to cope with those weaknesses? Which of those efforts worked, and which failed?
• What do you wish you knew “n” years ago about dealing with your company’s HR department?
• So that I can give the reader some context: Let me know how to refer to you in the article (at least, “Esther, a software architect at a Midwest insurance company”), and give me some idea of your company size (because the processes appropriate for a 70-person company aren’t the same for one with 7,000 employees).

You don’t have to answer all those questions! I asked these to get the conversation going. Tell me as much or as little as you like.

Please don’t assume that I think HR always sucks. However, there isn’t as much to learn from “why HR is your friend.” The idea here is to help techie managers cope when HR doesn’t offer what you hoped for.

Docker recently made it so that it requires you to have an account on Docker Hub in order to download the Docker Desktop Installer. So, here's the links:

https://download.docker.com/win/stable/Docker%20for%20Windows%20Installer.exe

https://download.docker.com/mac/stable/Docker.dmg

In the rare chance you haven't heard of Flutter, here's the link: https://flutter.io

Flutter just officially left beta with v1.0 December 4, last year. The code is written in Dart, and deploys on Android, and iOS (and will run natively on the rumored Fuchsia OS).

So for those of you that have used Flutter or are currently using Flutter.

• What are you working on?
• Why'd you choose Flutter?
• What do you like about Flutter?
• And what do you dislike about Flutter?

I'll start:

I'm working on a niche art app. I myself do not do that type of art, but knowing people that do, I wanted to create a tool to fill in the lackluckster market for Chromebooks and Android.
I chose Flutter because:

• I wanted to try something new, and what newer than something that was (at the time) in beta?
• Custom Views in Android are a hassle.
• I will be able to release on both Android and iOS (semi-)natively without having to code it twice.

Here's what I like about Flutter:

• Layouts are really simple.
  (though you can easily let it get clustered if you don't think too much about it.)
• Design isn't an afterthought.
  Animations are built in (and simple), themes aren't hard-coded, and Material Components get more attention here. (Still waiting for Shapes on Android)
• It's fast by design.
  Flutter uses its own custom rendering engine (Skia). I've never experienced any stutter with the built-in components, and when I caused lag (with heavy I/O) Flutter/Dart had tools in place for me to narrow down exactly what was causing it.

What I don't like about Flutter:

• It has poor mouse/trackpad support.
  Right clicks, not a thing. I can workaround this with a double-click/long-click, but for a desktop OS, this isn't optimal. Scrolling, that's panning, this should be differentiated. There's a difference between using a scrollwheel and moving finger around on the screen. According to Flutter there is not. There's also currently no support for mouse hovers which I have needed very much.
  There is a pull-request for adding support for all of these, but the developer hasn't done anything since code review.
• Keyboard support, while there, is lackluster.
  Ctrl, Shift, Alt. These have to be gotten with the meta code. There's no built-in function for checking those. Text fields don't support the tab key to navigate. And text formatting (bold, italic, etc.) isn't possible with text fields without the use of a library (or making it yourself).

I was trying to think of a third dislike, but I can't. My complaints are on missing APIs for Chromebooks. That's it. I really like Flutter, I plan on using it more, and if they won't add support for mouse/keyboard, maybe I'll have to contribute.

I'd love to hear what your thoughts about it is.

I have just graduated from uni, and am preparing for masters next fall. I'm a humanities student, but have some programming knowledge. Currently I'm looking for literary translation jobs, but should I fail that, I want to find some light freelance work (so that I can spare more time to my studies), and looking at e.g. freelancer.com, Wordpress is still quite popular.

What are some good introductory material for Wordpress and PHP, that preferably does not assume total beginner to programming? How much can I expect to make, for how much effort? I'd be content if I could make $200-250 w/ 3-5hr work per day, or a couple full days a week, that's all I really need and such hours would mean that I could keep on doing such work even when I'm writing my thesis. I'm in Turkey, FWIW.

^{For the uninitiated, you can visit puppylinux.org to get to know more about it.}

My first experience with Puppy wasn't good, since, for the life of me, I couldn't get the saves working. I still didn't, but I found that xenialpup does work for some reason, so I stuck with it.

After that, it's been great, and although I don't like the UI and some of the default apps, it worked on every computer I've tried it on, and it's light enough to run well on ancient computers.

As far as the tools go, it has everything I need to do my work, even if I'd prefer different tools (like vim and ranger).

That is, of course, only a problem with the default configuration, and Puppy has a very convenient tool to remaster itself, which I'll be using these holidays. It's great to be able to build a more welcoming version for yourself without needing any knowledge or spending a lot of time.

So, I just wanted to see what was your experience with Puppy, or, if you haven't tried it, what you think about it.

I've tried a lot of browsers. Starting from Chrome, to Chromium, to Firefox, to Links, to w3m, to, eventually, Qutebrowser, which I use for most of my browsing now.

At least for me, I had four things in mind while choosing a browser:

• I want it to be light
• I want it to be minimal
• I want it to be keyboard-oriented
• I want it to be able to use modern websites

I won't be going through all the browsers I've tried, but those I mentioned are the big ones, so I'll just do a quick check-list of these things.

Chrome/Chromium:

• Weighs like a sumo wrestler 1/5
• Cluttered 1/5
• Just some shortcuts and extentions 3/5
• The model, the idol to strife for 5/5

Firefox:

• Apparently lighter than Chromium, though not by much 1/5
• Cluttered 1/5
• Some shortcuts, famous extensions 3/5
• On point 5/5

Links:

• Very light and fast 5/5
• Minimal, though can go smaller 4/5
• Yes 5/5
• Doesn't support javascript 1/5

w3m:

• As light as it gets 6/5
• Pretty damn minimal 5/5
• Even works for blind 5/5
• Does javascript, but hard to use with cluttered wesites like Reddit or any news site 3/5

Qutebrowser:

• It is quite small and feels fast 4/5
• Can be easily modified to not have anything on screen, and command line-like controls 5/5
• Great, but hint system fails with javascript 4/5
• Doesn't work with Reddit, for some reason 4/5

With the things that I look for, Qutebrowser is the answer, with w3m being the close second. Of course, there are different things to look for in a piece of software, and you may want the extra stability and extensions Firefox provides, or privacy of Tor browser, or the suckless nature of surf, so I'd like to hear what is your browser of choice!

https://fastmail.blog/2018/12/27/jmap-is-on-the-home-straight/

Highly recommend to read the Dec 2014 post on what JMAP attempts to solve: https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/

UI changes on FastMail, making use of JMAP: https://www.fastmail.com/help/guides/interfaceupdate-2018.html

The JMAP spec and documentation: https://jmap.io/

Hi all, Hope ya'll doing good. I am done with windows. So I want to switch to linux. I have used it a few times. I just wanted to know, how long will it take to have it setup? Also, I am learning data science. Will switching to linux have any serious implications? Thanks

I'm currently researching the cheapest off site backup system and it looks like leaving a hdd at a friends house is the best option. The only thing I am stuck on is how to access it remotely. I need a system on a chip that I can plug in to the hdd and Ethernet and that provides ssh access. My first thought was a raspberry pi with a sata to usb cable but since I will only be doing weekly backups it makes no sense to keep the drive spinning 24/7. I need some way to turn off the drive and then back on over the internet. From what I understand there are linux programs that can do it but only directly over sata because the command doesn't work on usb sata controllers.

What I need is a cheap linux SoC that has sata and ethernet. Does anyone have any ideas?

So I am reading the cgroups manpage because I want to learn about... cgroups. It tells me that for CGroups V1, if I want to use specific features, my kernel needs to be configured. Either I missed a section or it isn't there, because I don't see much mention of kernel requirements for CGroups V2.

So, my question is, is my kernel ready for CGroups, or should I recompile? Should I be able to support both V1 and V2? The manpage says V1 was a heap, so I was thinking I might continue without it... ... ...

CONFIG_CGROUPS=y

# CONFIG_BLK_CGROUP is not set

CONFIG_CGROUP_SCHED=y

# CONFIG_CGROUP_PIDS is not set

# CONFIG_CGROUP_RDMA is not set

CONFIG_CGROUP_FREEZER=y

# CONFIG_CGROUP_HUGETLB is not set

# CONFIG_CGROUP_DEVICE is not set

CONFIG_CGROUP_CPUACCT=y

# CONFIG_CGROUP_PERF is not set

# CONFIG_CGROUP_DEBUG is not set

# CONFIG_NET_CLS_CGROUP is not set

# CONFIG_CGROUP_NET_PRIO is not set

# CONFIG_CGROUP_NET_CLASSID is not set

edit: wowie markdown fix

If you have built from source, then you know the relief when nothing interesting comes out of ./configure && make && make install. In fact, the less interesting the output of these commands, the better.

But occasionally, the source build process is so horrifying that you end up having to modify the configure script or makefile yourself.

So far I have only been able to do this when I was lucky enough to find some poor, destitute stranger who had pretty much the same problem as me ( most recent I can think of is GNUTLS, where I had to adjust the version requirements for nettle ) and that is a problem -- there must be some way to learn this myself.

Is this just something that comes with time and experience, or does anyone have a reliable guide or resource for modifying makefiles and configure scripts? I would appreciate advice / discussion: I am tired of "getting lucky" with these!

If you have never built one, you should -- it gives an in depth look at how different parts of linux interact with each other. Some of the methods used are outdated to be sure, but the first system is meant to be minimal, and a good base on which to build. I am lately working on a 'BLFS', and I'm learning even more.

Now, if I could just nail down networking ... ... ...

Any LFS experiences?