Today I Learned

0 readers
1 users here now

Today I Learned (TIL). You learn something new every day; what did you learn today?

founded 1 year ago
1
 
 

Some people might think you can only use or set environment variable of the service in docker compose eg.:

my-service:
  image: lts-alpine
  environment:
    MY_SECRET_KEY: ${MY_SECRET_KEY}

But the same ${} syntax can be used to set a version of Docker image of PostgreSQL, like in this example below:

my-service:
  image: postgres:${POSTGRES_VERSION:-13}-alpine

If nothing is set, version 13 is the fallback value. Now you can set POSTGRES_VERSION environment via your shell. Or leverage the .env file of Docker:

POSTGRES_VERSION=16

When running: docker compose --env-file .env up, Docker should now use PostgreSQL v16 Alpine as Docker image.

Bonus: The docker-compose.yml filename is an old filename, use compose.yml from now. Same for other Compose files like compose.override.yml.

More info: https://docs.docker.com/compose/environment-variables/set-environment-variables/ and https://docs.docker.com/compose/environment-variables/set-environment-variables/

2
 
 

Lemmy was/is vulnerable for XSS attacks.

Hackers try to inject JavaScript code that tries to steal your (ideally admin) cookie credentials. It seems that the admin account of lemmy.world was compromised this way (MichelleG). Other instances aren't safe either. Which could point to the custom emojis feature in the federate comments, meaning a lot of external instances could be effected by now.

Incorrect escaping of user input data could lead to these issues. Kbin just recently discovered a similar regression issue and which has been solved by now. But it seems that Lemmy was or still is vulnerable to this attack factor.

Mitigation action Lemmy users: You might want to disable JavaScript in the meanwhile.

Mitigation action for Lemmy server owner: Disable custom emoji:

DELETE FROM custom_emoji_keyword;
DELETE FROM custom_emoji;

Clean-up the exploit content:

UPDATE comment SET content = '<REMOVED BY ADMIN>' WHERE content LIKE '%![" onload%';
UPDATE private_message SET content = '<REMOVED BY ADMIN>' WHERE content LIKE '%![" onload%';
UPDATE post SET body = '<REMOVED BY ADMIN>' WHERE body LIKE '%![" onload%';
UPDATE post SET name = '<REMOVED BY ADMIN>' WHERE name LIKE '%![" onload%';

Rotate your JWT secret (invalidates all current login sessions):

UPDATE secret SET jwt_secret = gen_random_uuid();

Note: Even just opening a link to a vulnerable Lemmy instance could allow hackers to steal your cookies or sessions credentials. Therefore I will not share or allow people to share URLs of comprised / vulnerable instances.

3
 
 

Without proper CI/CD workflow jobs, errors are easily made without noticing it (or noticed too late). Especially when multiple developers are contributing towards your code base. Maybe your project is open-source?

When developing in a (large) piece of software, automated building & testing are crucial aspects to avoid regression impact of the code archive and even deployment.

The latest best practices are to setup a good and stable continues integration. Ideally also add a continues delivery setup for your project. Meaning that each pull request you receive will automatically try to build, test and deploy the code.
With testing I mean unit testing, functional tests, integration and E2E tests. And maybe UI tests if your application has a frontend as well.

Personally, I use GitLab for all my own projects, GitLab has a great CI/CD pipeline feature built-in their software. I'm running multiple GitLab runners, ready to pick-up requests. Which could be a unit-test running a Docker container, software build using GCC compiler or deploying my code live towards dev, acc and production.

Lacking such a well thought out CI/CD pipeline might result is build issues, regression issues or in the worst case down-time or unhappy users. Try to avoid this by using CI/CD for each of your open-source projects.

Have fun programming!

4
 
 

One of the main instances of Lemmy (lemmy.ml) is blocking 'kbinbot' user agent requests on their instance. Basically, they are blocking kbin instances. This is not a bug, but on purpose.

I couldn't find anything related in their source-code, so this is block is only present on lemmy.ml (or maybe some other Lemmy instances).

This is causing quite a lot of federation issues with Kbin instances. Resulting in various failed messages (from the messenger handler).

$ curl -I --user-agent "kbinbot" https://lemmy.ml
HTTP/2 403
server: nginx
date: Wed, 28 Jun 2023 18:35:27 GMT
content-type: text/html
content-length: 146
vary: Accept-Encoding

$ curl -I --user-agent "notkbin" https://lemmy.ml
HTTP/2 200
server: nginx
date: Wed, 28 Jun 2023 18:35:42 GMT
content-type: text/html; charset=utf-8
content-length: 163388
vary: Accept-Encoding
x-powered-by: Express
content-security-policy: default-src 'self'; manifest-src *; connect-src *; img-src * data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; form-action 'self'; base-uri 'self'; frame-src *; media-src *
etag: W/"27e3c-LCqXylkqSkDOy3K+3w2TijtMn14"
strict-transport-security: max-age=63072000
referrer-policy: same-origin
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 1; mode=block