shindoumihou / burp

Deploying smaller applications should be less complicated.

Hi, I'm Mihou! 👋

I'm a self-proclaimed full-stack developer with a specific love for backend development from the Bohol, Philippines. I'm currently primarily a Golang developer with Kotlin, Typescript, Svelte and Rust to create backends and frontends respectively. I plan to participate more in local meetups from where I am, so if you find me out there, feel free to hit me up!

about me

• i'm nineteen years old at the time of writing, and am currently attending a local high school.
• i used to, and maybe still, write webnovels and mangas, webtoons and comics are the epitome of me.
• i'm a photographer who also loves to make cinematographs and creating minimalistic graphics tends to be my hobby.
• i have a deep curiosity for anything that excites me, that's how i got into all my hobbies and even programming.

proud projects

some projects that i am proud of.

• flyght: bringing know-your-member system to Discord.
• notie: simply minimal, offline, notie-taking mobile application!
• siopao: bun-inspired file i/o in golang!
• threadscore: gamify q&a for discord. threadscore is a discord bot that gamifies questions and answers by adding a points system to threads.
• burp: a deployment tool designed for small-scale applications such as personal blogs. (powers Amelia and several other of my personal projects).
• guarde: a tcp-udp reverse proxy designed for adguard home and other self-hosted dns servers. (powers my home internet full of people with devices).
• git-uwu: a tool that makes your git commits uwu-ified.
• exponie.me: i was about to participate a spelling contest, but had no tool to help me practice... so i made one. (desktop client)
• ketshap: integration with github for discord (more detailed embeds, etc.)
• nexus: a kotlin-java discord framework for javacord that aims to be beautiful.
• amelia: a rss discord bot that was built for scribblehub.
• myrubberduck: a little rubber duck site with a mobile version
• nachos-go: a little Nats.io router that i use on some of my projects.
• sequelie: a little Golang SQL query loader that i use in some of my golang projects.
• primrose: a simple, open and markdown-based personal blogging platform written with Golang and SvelteKit, powering my blog.

legacy projects

some even older projects that haven't been updated for some time now and can be improved way more.

• mana: a discontinued discord bot that was the fuel for the start of my programming life.
• celestia: a logging stack that i used in production once for mana to trace errors and logs.
• youdiary: a personal diary written in sveltekit and typescript that is used to store personal notes.
• velen: the predecessor to nexus.
• rua: a simple rust reddit scraper.
• rosedb: one curious attempt at making a bad "database".
• flora: a simple, markdown-based, personal blogging platform written in svelte which used to power my blog.

there is more projects, but many of them are private sourced and have no plans right now to turn public... so that's all i can display for now.

show ur stack

some of the languages, tools and frameworks that i know and use.

• languages: kotlin (fave), java, rust, golang (fave and baby), typescript, c
• databases: mongodb (fave), redis, postgresql
• frameworks: sveltekit (fave and baby), react native (fave), laravel, wails (fave for making desktop apps)
• coding env: intellij, goland, webstorm, clion, fleet, visual studio code
• devops and monitoring: docker, docker swarm, sentry, graphite, grafana, prometheus, loki

i want to learn the following:

• monitoring: tempo

connect with me

you can hit me up in any of these platforms.

• discord: @s.miu
• email: [email protected]

burp's Issues

[FEATURE] Remove `insecureSkipVerify`

Originally, Burp uses insecureSkipVerify on the CLI to bypass the untrusted root certificate issue since most agents of Burp will be using a self-signed certificate. Instead, a better way around this would be to expose an unauthenticated route GET /certificate which will send the public certificate as a response.

During login, the CLI will open a connection to GET /certificate and save that certificate under $HOME/.burpy/certificates/$server_name where it will then be referred whenever a request to that server is performed. Although, this doesn't do much when a MIT (man-in-the-middle) attack is already on the client-side, but this mitigates the issue if the MIT is injected further after the CLI has saved the certificate.

[FEATURE] Analysis of `burp.toml`

Before deploying, Burp should be able to analyze the burp.toml to ensure that it is of specification and works as intended. It should check if properties that it requires are not null and so forth, this way, we can ensure that there is no mess happens. In addition, a command burp analyze should be added to help developers check if their burp.toml is missing anything.

[FEATURE] Cancellable Requests

Docker automatically cancels image builds when the client disconnects from the stream, Burp should also be able to perform similar action when the client disconnects from the stream, this doesn't happen because Burp processes the request in a separate goroutine which will keep going even after the client disconnects.

Branch feat/cancellable-request already handles this, but needs some testing and improvements.

[ENHANCEMENT] Disable request logger in `burp here`

As burp here spawns the same HTTP server as a regular Burp agent would, it also spawns the same middleware as a regular Burp agent has, and that is unneeded, especially the request logger which happens to show up at the end of the request. To make our logs cleaner, we can ignore the request logger middleware when the mode is in a certain mode (e.g. LOCAL).

[FEATURE] Better Composition

Burp currently has a composition that takes the main-dependency wherein services are written as either the main application or one of the dependencies, this works well with simpler applications, but for applications that require building one or more applications from a source, this falls apart.

As such, a new composition proposal needs to be implemented and this approach is the 'services' approach wherein all applications are regarded as a service and neither is considered the main application. In this approach, we create a schema as follows:

version = 2.0

[[services]]
name = "burp"
image = { build =  "/", repository = "https://github.com/ShindouMihou/burp" }
restart_policy = { name =  "always" }

[services.environment]
baseline = "burp.env"
server-side = false

[services.environment.replacements]
SIGNING_KEY="burp.Random(256)"

[[services]]
name = "redis"
image = { pull = "redis" }
restart_policy = { name =  "always" }

[services.environment]
baseline = "redis.env"
server-side = false

[services.environment.replacements]
REDIS_PASSWORD="burp.Random(256)"

To support this change, the environment.override will be removed and .env files will be merged into one separated by a comment that will signify to the processor of a new .env file such as in the example:

#burp: burp
BURP_SECRET={some argon2id hash}

#burp: redis
REDIS_USERNAME=root

In addition, future versions of the composition should support more file formats such as json, yaml instead of limiting towards toml which will help with how developers handle their preferences, for example, with JSON:

{
  "version":2.0,
  "services":[
    {
      "name": "burp",
      "image":  {
        "build": "/",
        "repository": "https://github.com/ShindouMihou/burp"
      },
      "restart_policy": {
        "name": "always"
      },
      "environment": {
        "baseline": "burp.env",
        "server-side": false,
        "replacements": {
          "SIGNING_KEY": "burp.Random(256)"
        }
      }
    },
    {
      "name": "redis",
      "image":  {
        "pull": "redis"
      },
      "restart_policy": {
        "name": "always"
      },
      "environment": {
        "baseline": "redis.env",
        "server-side": false,
        "replacements": {
          "REDIS_PASSWORD": "burp.Random(256)"
        }
      }
    }
  ]
}