DEV Community: Justyn Temme

AI Rubber Ducky

Justyn Temme — Wed, 11 Jan 2023 14:45:54 +0000

ChatGPT has taken the world by storm. There are a ton of use cases I have been playing with. The most profound of those being using chatgpt as a 'rubber ducky' feeding it code and an error in an attempt to solve the issue at hand. Unsure of which package has the needed functionality? ChatGPT may not give you an answer correctly the fist time, but given correct prompts and guidance can be a tool to rapidly speed up you development debugging.

When taking a piece of code to chatgpt one must be aware of the most efficient prompt templates that will generate the response we want, and not unrelated facts or formats. You can think of a prompt being the question we ask the AI.

Using code examples are a great way to give context to chatGPT about your current problem. Taking a main.go as the first prompt field, then on a newline, informing chatGPT exactly what we wish to do with that main.go.

Our prompt template can be thought of like this.

{Code example ie. main.go} {The request for new functionality specifying to edit the existing code and add a new function} {any specific guidance that may be needed}

To elaborate on the guidance, chatGPT may think something is a part of a package in Golang, when in fact is not. To give an example, I was asking chatGPT to explain how one might use a go function to load an executable into memory (more on AI runes later).

ChatGPT would get confused, and think packages that must be called via sys call.Syscall() could be called via the windows package. By looking at the original response we can add guidance that Windows does not contain the package it's looking for. More often than not, this would fix the response from ChatGPT to work as expected.

This is just a short way to use prompt templates to rubber ducky with chatGPT. I hope this can save you some StackExchange searches :)

Fenix: A new mobile browser from Mozilla

Justyn Temme — Wed, 08 Aug 2018 14:14:03 +0000

About the Project

Mozilla recently created a Github repository for a brand new mobile web browser named Fenix. Not much is known about this project. There has been no official statement from Mozilla at this time. A source close to the projects expects a usable project to land somewhere in 2019. With the current rate of code pumping out of the project I would expect that if not earlier. Sebastian Kaspari seems to be the lead developer with most of the commit history.

Technical Details

GeckoView

Fenix opts to use Mozilla's own GeckoView, rather than the default android webview. Geckos wiki mentions it is not quite ready for production, which leads me to believe a lot of the work going into GeckoView is specifically for Fenix. You can try out GeckoView by following the steps here

Nightly track on its way

Seven days ago, project lead Sebastian created an issue to set up a testing track on google play. This will allow developers and early adopters to get the first look at Fenix, and how it stacks up to other modern browsers.

Docker Build File

The project recently added a Dockerfile that builds all releases of the APK. The Docker project uses the same build chain, which makes it very simple for devs to help contribute to the project. All you need is docker and the other build dependencies are handled within the Dockerfile. This is a great Docker use case that more projects should be taking advantage of

Mozilla Public License V2

The project currently is Licensed as open source, under the Mozilla Public License Version 2

Testing

All of my test builds would not install on both physical Android devices, as well as device emulators. If you are able to get a build working on a certain version of android please email me at justyn@nextwavesolutions.io so that I can share images with how the current state of the browser looks. Until then I will be awaiting the testing branch to be deployed on the Play Store.

No IOS

It's interesting to notice that there is only an Android version of this browser. That is not to say development won't happen for IOS devices.

Contributing

Recently Ryan Sipes asked for clarification on build instructions to help contribute to the project. If you take a look at issue #55, you will see Sebastian recommend contributing to Mozilla mobiles android-components library. That is where a lot of the tools being used by Fenix are hosted. The third comment on issue #55 is a post written by myself detailing how to use Docker to build the apk's. Here you will find instructions on how to build and retrieve the proper APK.

Why I started contributing to Docker

Justyn Temme — Wed, 08 Aug 2018 13:35:14 +0000

Experience

Just like any spoken language, you must constantly immerse yourself in the language and culture to speak any programming language fluently. By dedicating a portion of my time to a single project, I force myself to come back to difficult tasks. Instead of abandoning a project for a new idea, I have a set amount of time each day I work through the problems I was facing yesterday. Dedicating yourself to a project builds grit, and you are more likely to finish bigger projects if you are already used to the rhythm of maintaining software.

Learning a big code base

Diving into a brand new project feels a lot like looking over a deep murky body of water. You are not quite sure what to expect, or where to start. That's the feeling we all get. Every single developer first looks over a code base with a sense of helplessness. Imposter syndrome or not, the more you work in a code base, or section of a large code base, the more familiar you are with how the larger picture works. You may feel you are not quite skilled enough yet, however developing an understanding of the entire code base starts by understanding a single function.

Career Development

Large companies actively seek open source contributors. to many managers, experience working with open source project is a great look for a resume. This establishes peer-reviewed skill in a certain language or topic. I have also had career opportunities open up because of certain projects I have worked with. Open source projects can be a great way to garner not only experience but resume bullet points as well.

Mentorship

While creating pull requests, your code will be reviewed and you might be asked for implementation changes. Rather than turn away, use these to better develop your skill in a specific language. Perhaps there was a much better way to implement a certain feature or a package in a standard library that does what your function seeks to do. Engaging with the open source community is one of the best ways to develop yourself as a developer. You will work with developers who have a lot of experience maintaining large projects, which will offer insight you may not have been able to see before.

A better understanding of Docker

I had always thought Docker was some cool tech but didn't really deploy it until I started contributing. After I started seeing some more niche use cases thanks to issue tickets and bugs, I started to deploy docker in my own tech stack. Having already studied the code base, I was familiar with how things worked underneath Docker. This gave me a better understanding of not only how Docker is used, but why certain limitations exist.

Contributing tips

Beginner Tags

You can often find documentation edits, as well as beginner-friendly edits, tagged as issues in a repository. These will help you learn the contributor workflow, or how pull requests are typically handled. Many bigger projects will have contracts you are required to sign before contributing or other stipulations. Even as a seasoned developer, these beginner tags are great to work on to introduce yourself to the community, and learn the culture and workflow behind the project.

Patience

Not every pull request can be answered quickly. Often times a project has way too many to process. Use this time to implement tests in your code. Check the CI builder and see if your code fails any test units. Make sure your code is linted and formatted according to contributor guidelines. This will make the merge happen much more smoothly if maintainers can focus on the implementation rather than styling nuances of your pull request.

Docker to Kubes

Justyn Temme — Wed, 25 Jul 2018 13:54:46 +0000

If I told you that the transition from Docker to Kubernetes takes an afternoon of seamlessly migrating containers, I would be lying.

Kubernetes force me to abandon my love for docker-compose. I had to rethink my container orchestration. I would be ditching my well-tweaked Nginx SSL proxy and adopting the “serverless approach”.

Serverless

I never really understood the benefit of serverless architecture. Serverless? Really? That’s for lazy people, I thought. How wrong I was.

Adopting this approach forced me to think in more depth about how my application would interact with its data and the network in which it exists. I created a container that did not depend on any external data to run. I had been told many times to not include SSL certs in my containers, however, I now do in order for proper scaling to be achieved.

Scaling

When I finished creating my stateless application I deployed three instances of it behind a load balancer. Proper scaling had been achieved. With a few clicks, I am able to run as many as even a thousand instances of my application. This is precisely what the serverless architecture is designed for. My applications load holding ability is no longer dependent on just one server, but many servers spread out across the eUnited States

Persistent Volumes

Typically when setting up persistent data with Docker, one would mount persistent volumes to a parent server. This allows for easy container creation and removal without the fear of accidentally deleting important data, which, is similar to what Google Cloud Platform has to offer. However, it is important to note the persistent volumes claims, Googles approach to permanent data storage can only be accessed with reading / write permissions by a single container at a time. This means the volume can’t act as a storage area for SSL keys for all containers. While it’s generally not a great idea to keep SSL keys in a container image, this is the only solution I have come up with for this issue.

Persistent Volumes are tied to clusters. You may delete workloads, as well as containers, networks, and services. However, it is important to note that when deleting a cluster, you will be deleting all of its corresponding volumes.

Load Balancing / Nginx

As mentioned previously, NGINX load balancing does not work as expected. While probably possible with some proper setup, the simplest method is to use Google’s provided load balancer. I wish I could share some data on how my application was able to handle the significant load from stress testing, but I can’t report that as Google detected automated traffic as a DDOS attack and blocked most requests. So I guess that’s a win for the load balancer

The Google Cloud Platform offers several methods ways to access containers within a node. It is possible to create a direct link exposing a port on a node to an outside source, however, this lacks the scalability and load balancing sought after in Kubernetes. Most often, a load balancer is used to process the request, and forward them to the correct node port. The load balancer will take into consideration resources, as well as which nodes are healthy due to a health check.

When first using the load balancer I had attempted to handle SSL/TLS on the load balancer. While this is possible, it is not ideal. Wordpress will have a difficult time telling if the connection is secure. This is just an example of issues with WordPress behind an SSL reverse proxy. It seems the better solution is to build your image to scale, handling the secure handshake at the container, and letting the load balancer handle what it was designed to do, load balance.

Cost-Benefit analysis

Overall I am spending the same amount on the Google cloud platform that I was spending on my dedicated server. In time this will probably outgrow my spending if budget allows. While you could probably make more use of a single server for a small network if you are looking to scale your application the cost of using a Kubernetes engine is hands down the best method. I am unaware of any application that allows for the scaling Kubernetes engine does.

Is it worth it?

If you are running a single static website and are very interested in how Kubernetes works, then yes it’s very much worth it. If you are running several development projects and need to keep them running 24/7 with updates, then it is important to note Kubernetes will take time to learn. Even while staying fairly simple, you must relearn everything you did with Docker. Overall I have thoroughly enjoyed the time I have spent learning Kubernetes, and as someone seeking employment in that industry, knowledge of how to scale applications with an engine such as Kubernetes is crucial to career development. Kubernetes doesn’t really affect the small project hobbyists, instead focusing on how to take on the challenges of scaling for rather large applications.

Choosing the right tool: How to pick the right programming language

Justyn Temme — Wed, 25 Apr 2018 14:32:50 +0000

Jack of all trades, master of none. Often better, than a master of one.

Adam Savage

Master of one

When I first started programming, I had figured I would learn python. It was easy enough for a young me to learn. It was powerful and could do a whole lot. I told myself the more time I spent in this language the better I would be. I spent about two years learning python. It taught me a lot about programming. From variables to functions, user input, all the basic stuff we learn in our intro classes.

Jack of all trades

Python was not where I stopped. Shortly after I picked up C, and watched many courses available online to study more programming theory. I understood how efficiency is measured in a program, and how to avoid a lot of the common mistakes programmers make. By the end of that, I had the ability to understand large code bases, and proper program structure. At the core, I knew how the language was interacting with the operating system, and how my instructions were then interacting with the device drivers. Because of my early python experience, if I didn't quite need to full C suite of tooling, I could quickly script something together as well. My tools were expanding.

Go Go Speed Racer

Enter Golang, and specifically Todd McLeod. Having access to the internet meant I had a wealth of knowledge at my fingertips. Hearing about this exciting programming language coming from Google I had decided to pick up a class on it. Perhaps It could teach me some things I didn't already know about programming. That is exactly what happened. Learning Go gave myself an abstraction layer above C. A lot of the data models and structures I had learned to create by hand, or with helper libraries, came default in Go. I was able to use my knowledge of how C worked, and rapidly build applications with a great set of libraries and frameworks for the Go language. My understanding allowed me to jump into the Go source to see how certain things were implemented, and understand how to best use them because of this.

The glue of the internet

Well, there comes a time in a developers life when it is time to start making money on your acquired skill and ability. As much as I had wanted Red Hat to come knocking on my door, they didn't. So instead I picked up a client to build backend services that held together with a few different APIs. The language for the project was javascript and jQuery. I picked up a jQuery book from Barnes and Noble and within two weeks was building production applications being deployed to clients. I do not write this to exclaim my ability as a person, but to highlight how understanding the different layers of the application, and wide variances in languages, meant javascript was simply a syntax learning exercise, rather than learning a whole new idea or philosophy.

How to choose right programming language

When an Idea comes into my head I quickly whiteboard how the different pieces of the application will work. How will the front end user interface interact with the backend database? Will the UI be simple enough that a heavy framework would be cumbersome and limit to work with? These are questions I ask myself when designing and choosing the tool for my software. VueJS has become a favorite framework of mine for the flexibility. However, when building an application for the app store, I have to understand React will feel worlds different to users, and still allow developers to work with javascript frameworks. Understand how each programming language has its advantages, and disadvantages, allows me to select the right tool for the job. Golang is perfect for a backend REST API, however, unless it's your sole language, building a simple single page application in VueJS can be done a whole lot faster, with less code, and allow for many other programmers to contribute code. Languages are tools by which we build our application. Build your toolset as a developer, and think about how each task would be done most efficiently. Do not use hammers to screw in nails. This will build a faster workflow and happier developers.

Read more articles by Justyn at https://nextwavesolutions.io

How to DOS Yourself With Argon2

Justyn Temme — Thu, 12 Apr 2018 19:28:43 +0000

Recently while penetration testing a clients server I found a DOS attack via a simple post request. On a page which took text input, as well as a hashing method, and returned the hash string, I was able to DOS the entire server.

Starve the CPU

The exploit was a simple bash script that made a POST request with the text as testing and the hash function, Argon2. Now one interesting thing to note is exactly how much CPU usage each hash function takes. Many would consider this all the more reason to use Argon2 over a weak hashing function like MD5, I would agree. The issue is not within Argon2. It is a much superior hashing function. However, when a small 1 core 512mb digital ocean droplet is told to hash strings thousands of times, one after the other, the CPU usage quickly goes from idle to 100%. This caused the entire server to stop responding until we stopped the script.

Mitigations

Just how can we stop attacks like this from occurring? Well as with all security, it must be thought of during the design of the software. The entire system must be taken into account as a single functioning body with many parts.

Efficiency O(o)

When engineering any piece of software, from API to full-scale application, one must think of efficiency of the entire system. Does the size of the request, match the amount of processing it would take? Many would consider this to be O(o), or amount of time grows linearly with the size of the input. You can find the explanation referenced and more information on Big O notation explained very methodically here.

Rate Limiting

If the goal of efficiency simply can not be met due to requirements of the software, one can look to limit the rate at which requests can be made, otherwise known as rate limiting. By stopping an attacker from leveraging an inefficient request, you can allow the server enough time to complete the function and return for the next, rather than dying a slow death.

Rate Limiting an API in Go

It's well documented Go is my favorite programming language. Once again I get to explain how simple it is to create secure effective apps using the tooling built into the language. As expected with most things, goes implementation of rate limiting is basic enough to be used by any junior developer, and scales with tools and would make any senior developer ecstatic.

import "time"
We will start by importing the time package. This will allow us to dictate the frequency we allow requests.

rate:= time.Second / 10

burstLimit := 100

tick := time.NewTicker(rate)

defer tick.Stop()

Here we are defining the options for our limiter, as well as implementing a burst limit to allow for fast response calls, and still limit the amount in a given time frame.

throttle := make(chan time.time, burstLimit) This will create a channel that another function can peek into and see the time or burstLimit. This will allow us to use go routines to manage requests.

go func() {

  for t := range tick.C {

    select {

      case throttle <- t:

      default:

    }

  }  // does not exit after tick.Stop()

}()

This is the goRoutine that will tick the timer forward, and at every tick, check if the requests are greater than the burstLimit.

for req := range requests {

  <-throttle  // rate limit our Service.Method RPCs

  go client.Call("Service.Method", req, ...)

}

Here is our final piece of code. This will look through the requests and check tick the counter within the channel the goRoutine uses. If tick.Stop is not called then the service request will carry on as normal. To see the full source code, as well as see more advanced rate limiting implementations visit the Golang Wiki

You can read more of my work here