Earlier today, we have migrated our backend service to run our new @freesewing/backend:v4.7.0 container image.

This minor release of FreeSewing (v4.7.0) is almost exclusively dedicated to changes in our backend code (and flanking changes required to adapt our frontend code to those backend changes).

As far as we know, we are the only people who run a production FreeSewing backend, but the world is a big place, and we do make our Docker images freely available for anyone to use. So:

If you are running FreeSewing backend code, upgrade to v4.7.0 now.

We’ll get to the details below, but let’s first set the stage.

Security audit of the FreeSewing backend code​

The sweeping range of changes rolled out today were triggered by a security audit of our backend code by Alen Sarang Satheesh (alensarangsatheesh@gmail.com).

Alen is a freelance security researcher based in Kerala, India, who volunteered their time to perform this audit.

Any security audit is a particularly valuable contribution to make to an open source project. In this case, it also allowed us to address some issues that we frankly are relieved to see fixed, but more on that below.

We would like to thank Alen for their valuable contributions to FreeSewing. We are also truly appreciative of the responsible disclosure, not to mention the professional manner in which we were able to cooperate on mitigations.

Your data is safe​

Before we dive into the various things that came up in the audit, and the steps we have taken to address those issues, I want to be clear about the impact:

While the audit did reveal issues that could have been abused to allow data leakage or privilege escalation, we are unaware of any of these issues being exploited. We are also unaware of any data being leaked, and we have – apart from the accounts used by the security researcher themselves – not found any account with a privilege level that was not what it should be.

In other words, while there were some real issues, those issues seem to have remained dormant prior to the audit. The data of our users, and the security of our systems, has thus not been impacted.

There is one caveat, and that is that this is as far as we can tell. It is always hard to prove a negative, but we are confident no harm was done.

We made mistakes. And when we say we, we mean Joost​

As FreeSewing’s maintainer any problems are ultimately my responsibility. However, in this particular case, the matter is much more clear-cut since our backend code is not an area that typically attracts a lot of contributions.

So I (joost) take full responsibility. Not merely in a I’m in charge so I’ll take the blame way, but in a much simpler I wrote all the problematic code myself way.

That being said, I don’t think that assigning blame is very useful. Instead, we will use this as an opportunity for growth.

We’re in a much better place today than we were last month. Lessons were learned, short-term fixes were rolled out as soon as possible, mid-term fixes were deployed earlier today, and we have already started working on implementing long-term changes to ensure we are better prepared going forward.

Summary of noticeable changes​

I will unpack the various changes with a security impact below, but for the casual reader, I have summarized the changes that will be most noticable to FreeSewing users below:

Migration of transactional email from AWS to Scaleway​

We have migrated our transactional email provider (transactional emails are emails you receive to confirm a sign-up request, an email change, and so on) from Amazon Web Services (AWS) to Scaleway.

This is part of our overarching migration from US-based tech companies to EU-based alternatives. A migration that – in combination with the image hosting changes outlined below – is now complete.

As a result, transactional emails from FreeSewing will be sent out from the no-reply@notifications.freesewing.eu address. Feel free to allow-list that address if you are concerned that our emails might get tangled in your SPAM filter.

The Reply-to address will be support@freesewing.eu so that you can still simply reply to the email to reach a human being.

Migration of image hosting from Cloudflare to Scaleway with Bunny CDN​

The final service to migrate away from US-based tech companies was our image hosting, which until today was handled by Cloudflare.

There was no drop-in replacement for Cloudflare’s Image API in the EU, as it is a rather custom setup. So instead, we have decided to take matters into our own hands, and host the images ourselves on our backend systems.

To protect our backend from the incurred bandwidth costs, we have furthermore opted to deploy Bunny CDN in front to allow caching of these images.

Migration to UUIDs to identify database records​

We have migrated all monotonically increasing IDs to UUIDs to identify database records, like users, patterns, and so on.

A monotonically increasing ID is a difficult way to say that the ID is an ever-increasing number. The first user gets ID 1, the second gets ID 2, the 100.000th user gets ID 100000 and so on.

Such numbers work fine, but they have the disadvantage that they are predictable. This is especially relevant when you expose some data via API endpoints. For example, if the backend returns (public) info about a user by polling the /users/[id] endpoint, then one could just loop through numbers 1 to 100.000 to scrape data about 100.000 users.

To prevent this, we have added UUID fields and those are now required to pass as identifier, which blocks such scraping attempts.

For the most part, this will be transparent to users. Except if you have bookmarked any URLs that have a record ID in them.

Implemented rate-limiting​

To prevent brute-force attacks on authorization endpoints, and to prevent abuse in general, we have implemented rate-limiting on our backend.

This should not impact regular users, but will guard against bots, scrapers, as well as malicious use of the API, such as brute-force attempts to break into accounts.

Vulnerabilities found in the audit​

The remainder of this report outlines the steps that we’ve taken in light of the responsible disclosure of several security issues in the FreeSewing backend by independent security researcher Alen Sarang Satheesh.

Notes:

• All fixes are present in the latest v4.7.0 release
• The most sensitive fixes were already fixed in the v4.6.0 release
• Those sensitive fixes have also been backported to the v4.5.0 release
• All times in this report are CET.

1. Stored XSS vulnerability​

This was due to a lack of sanitization on usernames prior to embedding them into an SVG. Given that an SVG image can also include Javascript, this opened the door to XSS attacks by a malicious user through careful manipulation of their username.

We initially fixed this – as an out-of-band quick fix – in:

• [backend] security: Sanitize username in SVG output

But given that the original use-case for this endpoint is no longer valid, we later decided to remove this endpoint altogether:

• [backend] chore: Remove user card endpoint

Timeline

• Disclosure: Thursday, March 05, 2026 06:52
• Fixed: Thursday, March 05, 2026 12:40

2. Critical IDOR Vulnerability Allowing Unauthorized Access to User Data​

This was due to a bug where we did not enforce a check that the data being accessed matched the authenticated user. The bug was thankfully limited by the fact that this endpoint does not decrypt data. So the returned data was only data that was not deemed sensitive enough to be decrypted at rest in the first place.

Fixed in:

• [backend]: Enforce authenticated user ID check in account data endpoint

Timeline

• Disclosure: Thursday, March 05, 2026 16:03
• Fixed: Thursday, March 05, 2026 17:54

3. User Enumeration via /users/:id/card​

As a short-term fix, we have removed this endpoint altogether:

• [backend] chore: Remove user card endpoint

Timeline

• Disclosure: Friday, March 06, 2026 03:53
• Fixed: Saturday, March 07, 2026 16:29

4. Confused Deputy via Cloudflare Images API​

This reported issue is that users can not only upload images, but also specify a URL to fetch the image from. That in turn triggers a request to fetch the image from that URL, a URL that is controlled by a potential attacker.

However, this is a feature of the Cloudflare Image API. FreeSewing does not fetch the image, cloudflare does. And although this request is on our behalf, it does not contain any privileged information.

Given that the root cause is in the Cloudflare codebase we can only implement guardrails. As such, we have decided to prioritize our migration away from Cloudflare, a migration that is now completed.

Also note that we have changed the way we manage images so that we only accept uploads, and do not support fetching images from an URL.

Fixed in:

• wip: Work on refactor of backend code
• [backend] chore: Handle image uploads after migration, support tests

Timeline

• Disclosure: Friday, March 06, 2026 03:53
• Fixed: Friday, March 27, 2026 08:52

5. Unauthenticated privilege escalation to site administrator​

This reported issue exploits the special exemptions carved out for unit tests in the code base. To trigger the exploit, it leverages an operator precedence bug in the code that is used to test whether a particular request is part of a unit test. Once the system is tricked into believing it is a test, it then goes on to exploit some of the logic that only applies to the unit tests:

• Allowing users to sign up with any role
• Forgoing the need for email confirmation

When you string this all together, the end result is that an attacker can create an admin account by manipulating the request to the signup endpoint.

This one is real bad, although it does have the advantage that it allows us to check for unexpected accounts with an admin role in the database. We found 8 of them, all created close to each other, and we confirmed that they were all created by the researcher who reported the issue.

We initially fixed this – as a production hot-fix – by making the isTest() method always return false.

We then proceeded to remove all unit-test specific code paths from the code base:

• [backend] chore: Remove all unit-test code paths

Today, we no longer have any special code paths for unit tests.

Timeline

• Disclosure: Friday, March 06, 2026 15:55
• Fixed: Friday, March 06, 2026 16:28

6. Wildcard CORS configuration​

The FreeSewing backend accepts cross-origin resource sharing (CORS) requests from any site.

This is by design. The FreeSewing backend API is a public, open API that explicitly supports third-party integrations.

The risks of liberal CORS headers are predominantly tied to browser-managed credentials – such as cookies, basic authentication or TLS client certificates – as they are automatically included in requests. But the FreeSewing backend relies on JWT bearer tokens, which need to be explicitly set.

As this CORS configuration is by design and stems from our commitment to openness, we do not want to change it.

However, while we were addressing the various issues in this report, we have decided to lock down CORS as a cautionary measure. Even if doing so broke user’s development environments, as well as community-lead initiatives that publish alternative FreeSewing frontends with early-access designs.

Now that all issues are resolved, we have gone back to be an open API that can be used by anyone.

Timeline

• Disclosure: Friday, March 06, 2026 03:53

7. JWT Misconfiguration​

This reported issue bundles two different points:

• Information Disclosure
• Excessive Token Expiry

The information disclosure report points out that the inclusion of http://localhost:3000 in the token leaks information about the internet configuration. While that does not grant any access as-such, it provides valuable reconnaissance data.

We’d like to point out that as an open source project with a commitment to transparency, this information is available in our repository for anyone who takes an interest in how things work under the hood.

As for the excessive token expiry, the current expiration is 28 days. Shortening it, especially significantly shortening it, would impose a real inconvenience cost on all of our regular users for little gain in security posture. An attacker gaining access to a token can do damage in minutes. No amount of shortening the length of the token is an effective strategy to guard against that.

There are of course the issues that are inherent in the choice for JWT, in particular the inability to revoke them. As such, there is certainly room for improvement here, and as such we have added the implementation of refresh token rotation to our todo-list so that we can use short-lived tokens without sacrificing our user’s convenience.

As this would require a good bit of engineering, we have added it as a todo, but we have not completed (or even started) that work at this time.

Timeline

• Disclosure: Friday, March 06, 2026 03:53

8. Magic link account takeover via token leakage​

FreeSewing offers a ‘magic link’ sign-in mechanism. Since all the information to sign-in if included in the URL, this allows anyone who has access to the URL to sign in as the user in question.

This is not a surprise as-such, that’s the way it’s supposed to work. It is also worth pointing out that once-consumed, these URLs will no longer function.

The report suggests to implement strict referrer-policy headers to avoid the URL leaking during pageload in the referrer header when loading third-party resources.

While that does provide some limits to the URL leaking out, it does not address other places where the URL can leak, such as intermediate proxies and access logs.

As such, we feel the better approach here is to move away from having all information contained in the URL, and instead require a flanking one-time code that we would include in the email. We had initially added this more in-depth defense to our todo-list. However, we have since implemented it, and it is part of the v4.7.0 release.

Fixed in:

• wip: Work on refactor of backend code

Timeline

• Disclosure: Friday, March 06, 2026 03:53

9. Sensitive Data Over-Exposure​

The endpoint returning user’s account data includes data that – according to the report – should not be shared with the user. Specifically:

• ehash: An unsalted hash of the user’s current email address
• ihash: An unsalted hash of the user’s initial email address
• intial: The user’s initial email address
• mfaEnabled: Whether or not MFA is enabled on the account
• passwordType: The underlying type of password – to support migrating old accounts

We have removed ehash, ihash, intitial, and passwordType from the returned data. We did not remove mfaEnabled as we need it to let the user know whether they have MFA enabled or not.

As the report mentions that ehash and ihash are the unsalted hash, we feel we need to clarify their use.

As we practice encryption-at-rest, we cannot do things that one would take for granted, like finding a user based on their email address, as that data is encrypted.

This is where ehash comes in. It is a hash of the email address, which allows us to search for a user based on (a hash of) their email address. While it is true that this allows an attacker with access to the account data to confirm the email address, an attacker with access to the account data already has the email address, so this seems like a moot point.

The ihash field serves the same purpose as the ehash field, but for the ‘initial’ field. This field holds the email that the account was initially created with. The report flags this as a risk, saying that users who want to change their email address to a burner address will still have their initial email in their account data, thus undermining their anonymity.

While that is the case, if you want an anonymous account, you should create one with a burner email address, and not turn a nominative account into an anonymous one. In addition, the reason we keep the initial/ihash fields and do not allow users to change them is to protect against account take-over and resolve disputes about account ownership. In practical terms, when an attacker succeeds in taking over an account and change their email address, the initial field allows us to know what email address was used to initially create the account.

Timeline

• Disclosure: Friday, March 06, 2026 03:53
• Fixed: Saturday, March 07, 2026 16:29

10. No rate-limiting on any endpoint​

The FreeSewing backend does not implement rate-limiting.

We have not implemented rate limiting because we have not observed abuse patterns that would necessitate this. Still, we recognize it is good advice.

We had initially added rate limiting to our todo list. But we have since implemented it and it is part of the v4.7.0 release.

Fixed in:

• [backend] chore: Hardening and rate-limiting

Timeline

• Disclosure: Friday, March 06, 2026 03:53
• Fixed: Friday, March 27, 2026 08:52

11. Encryption key reused as JWT secret​

The same key is used for AES encryption and JWT signing. A compromise of the key would compromise both encryption and authentication tokens.

A compromise of FreeSewing backend encryption would be a significant incident. It seems difficult to imagine a scenario where the encryption key would be compromised but the JWT signing key would somehow not be. As such, this risk feels theoretic.

Nevertheless, we have implemented the suggested change and created a different key for JWT signing.

Fixed in:

• [backend] chore: Hardening and rate-limiting Timeline

• Disclosure: Friday, March 06, 2026 03:53

• Fixed: Friday, March 27, 2026 08:52

12. Missing common security headers​

The following headers are listed in the report as missing:

• Strict-Transport-Security (HSTS)
• Content-Security-Policy (CSP)
• X-Content-Type-Options
• X-Frame-Options
• Permissions-Policy

Most of these headers are relevant in the context of an HTML page. As a REST API the returns application/json several of these are not relevant.

The ones that are:

• X-Content-Type-Options: This has minimal practical impact for an API that always returns JSON, but adding it is also not a problem. So we will.
• Strict-Transport-Security (HSTS): This enforces TLS. Note that we already enforce TLS server-side by redirecting all HTTP requests to HTTPS. However, as HSTS impacts the client side, it would be an improvement to add it. That being said, adding this to the backend code would also impact the developer experience as running the backend API in development mode on localhost would also require a TLS certificate. So, rather than add this to the backend code, we will add these headers at the reverse proxy level.

We have added these headers on our reverse proxy.

Timeline

• Disclosure: Friday, March 06, 2026 03:53
• Fixed: Sunday, March 08, 2026 09:22

13. Account modification without re-authentication​

Once logged in, users can change account settings such as email, username, bio, and password without re-entering their password.

Note that changing MFA settings does require re-authentication, and email changes do require email confirmation. What account properties require re-authentication is a choice to be made. We do not feel that re-authentication is required to change one’s bio or username.

Requiring the password to change one’s password would be a problem as we do not create a password for FreeSewing users when they sign up, instead relying on a magic link and confirmation code.

Users can set a password if they do choose, but asking for a (non-existing) password at this time would break that.

Still, we take note of the remark. Support for passkeys is on our roadmap, so we will re-visit this matter at that time.

Timeline

• Disclosure: Friday, March 06, 2026 03:53

14. No CSRF protection​

CSRF (cross-site request forgery) tokens are a mitigation for cookie-based session authentication, where the browser automatically sends the authentication with the request.

As our backend uses JWT bearer tokens, it sidesteps CSRF entirely. As such, CSRF protection is not relevant in our case.

Timeline

• Disclosure: Friday, March 06, 2026 03:53

15. Universal input sanitization failure​

User provided data is stored without sanitation.

This is about data such as usernames, bio, titles of bookmarks and so on.

Note that this data is properly escaped to handle SQL-injection and is escaped in FreeSewing’s React-based frontend. As such, the issue is predominantly a a risk for future or non-official API clients.

Still, we should not let a footgun like this linger and we will take this remark into account for future refactoring of our backend code – an effort we have already started, having recently removed the Prisma dependency in favor of native NodeJS sqlite bindings.

Timeline

• Disclosure: Friday, March 06, 2026 03:53

16. Sequential/Predictable user IDs​

FreeSewing uses numeric account IDs which allows account enumeration.

As a short-term fix, we have removed the profile access endpoint:

• [backend] fix: Disable anonymous profile data endpoint

As a more in-depth defence, we have migrated to UUIDv4 as record identifiers. As this required changes in many different parts of the codebase, we have opted to forego a list of relevant commits as it would be too long.

Timeline

• Disclosure: Friday, March 06, 2026 03:53
• Fixed: Friday, March 27, 2026 08:52

17. Account spoofing via record cloning​

A bug in the cloning logic for patterns, measurements sets, and curated measurements sets failed to re-assign ownership of the data to the user initiated the clone operation. This caused data to be stored in the user who originally owned the data, rather than the user who initiated the clone.

Fixed in:

• [backend] chore: Port patterns to UUIDs

Timeline

• Disclosure: Sunday, March 08, 2026 16:18
• Fixed: Sunday, March 08, 2026 16:23

18. Authorization Bypass Vulnerability due to insecure OIDC session handling​

Due to an incorrect handling of the OIDC state, it was possible for an OIDC flow initiated by user A to be completed by user B. This opens the door to tricking users to complete an OIDC flow they did not initiate.

The OIDC flow is (only) used to authenticate users on the FreeSewing forum, as such the scope was limited to the forum.

Fixed in:

• [backend] security: Refactor OIDC implementation

Timeline

• Disclosure: Monday, March 09, 2026 05:53
• Fixed: Monday, March 09, 2026 07:26

19. No upper bound on API key expiry​

A bug in the lookup for the maximum expiry of user-created API keys allowed users to create API keys that expire so far in the future they are de-facto never expiring.

This was a minor issue, caused by a typo in the configuration lookup for the maximum expiry.

Fixed in:

• [backend] fix: Incorrect config lookup for api key max expiry

Timeline

• Disclosure: Tuesday, March 10, 2026 17:59
• Fixed: Wednesday, March 11, 2026 08:19

Summary​

The security research performed by Alen Sarang Satheesh revealed a range of security issues in the FreeSewing backend code, including a particularly dangerous admin account creation bug, as well as a cross-account data access bug.

Other issues were less problematic, and some were not particularly relevant to our specific setup. But overall, the research was extremely valuable.

We have implemented fixes for the most urgent matters as soon as possible, and have worked over the last three weeks to implement those fixes that required a more substantial change in approach. We have also implemented the various recommendations insofar as they were relevant.

While we have strived to do all this with as little disruption as possible to our users, the last couple of weeks we have had an increased error rate due to the temporary fixes we had put in place prioritizing security over functionality or user experience.

We would like to thank Alen once again for their excellent work, and we would also like to thank our users for their continued trust in FreeSewing.

If you’ve read this far, you will have realized that we are not perfect. But we do our best, and you can count on us to be honest and open when we get it wrong.

We have just released FreeSewing v4.6, which comes with a new design (crux) and a new plugin (plugin-transform), as well as a bunch of other incremental improvements. Check our CHANGELOG for all details, or read on for the highlights.

Crux Climbing pants​

Wouter signed for this design, the Crux Climbing pants. He writes:

I’ve been wanting to make pants that I can use while hiking or climbing. Because all the other pants I wear I make myself. Just for some reason, I have not made this type of pants. And it’s been bothering me that I still have to go to the store to buy them.

I used cornelius as a base, and then quickly started to tweak to something that works well for the new task. Since I have quite some hiking pants, and have seen numerous ones being offered, I tried to incorporate some of the features I see in commerical ones.

There are different pocket options, the ability to have the pockes be on the inside or outside, cargo or patch, etc.

An option to make articulated knees is included, as are different hem and waistband options.

These work well with medium/light bottomweight woven fabric with a slight stretch along the weft. But you can make them with any fabric option you prefer.

Wouter

The new transform plugin​

We also have a new plugin, named plugin-transform that brings the transform macro.

It allows you to apply a transform – so either scale, rotate, or translate – to one or more points or paths. Similar to what you can do in CSS or SVG.

Backend changes​

This release also includes some changes to our backend, including some changes that will cause some breakage. This is part of an ongoing effort and we will have more to share on this in the near future.

We have just released FreeSewing v4.5. It’s a big release with a plenty of under-the-hood changes.

As usual, our changelog has all the details of what went in this release. Here, we’ll focus on the main item: The FreeSewing Library.

The FreeSewing Library​

Ever since the release of version 3 of FreeSewing, we’ve supported the ability to freely combine different parts from existing designs as part of a new design.

It was – and remains – a good idea and a feature we absolutely want to support. But over time, we’ve seen that in practice, this can sometimes lead to problems:

• It takes careful design to ensure a part is created that can stand on its own without making assumptions about the design it is used in
• Pulling in a part from a design as a dependency often brings along a bunch of stuff of that design we are not interested in

People have also been extracting parts from designs that were never intended to be used outside of that design. This often required a bit of a hack to make it work, which saddles us with technical debt and code that is difficult to maintain.

So this created tension between the set of features we are committed to support, and the way those features sometimes were used which caused concerns about maintainability.

So, after some discussion on the matter, we’ve decided the create the FreeSewing Library. It is just another design named Library but it’s raison d’être is not as a stand-alone design, but rather as a Library for commonly used parts that are explicitly created to be re-used in other designs.

How does it work?​

This works just the same as any other inheritance that we’ve been using before. It’s really just a matter of creating a growing body of ready to be reused parts which people can use.

That being said, we’ve made a bunch of changes under the hood to make sure this works in a way that is elegant. Such as allowing to reuse a part more than once with different settings, or the ability to scope design options to a specific part, rather than to the entire pattern.

Inheritance is here to stay​

This does not mean that it is now bad to inherit parts from designs that are not the library. In particular, extending blocks into more fully featured patterns is not going anywhere.

What we wanted to avoid is a growing number of ad-hoc dependencies that some designers were creating, which makes it really hard to maintain the software. The people who maintain our foundational blocks are typically seasoned FreeSewing contributors, which is a good thing as every change to these blocks has ripple effect that impact many other designs.

By perhaps somewhat overeagerly re-using parts from various designs that were never intended for that, other designs (and designers) are now also faced with the delicate balance of maintaining not merely a design, but rather a library that is used by other designs.

So, we figured we would instead formalize this and create a proper library. The message we want to send to designers is:

• Inherit from our blocks, it’s what they are there for
• Reuse what’s in our library as much as you want
• Reach out to us before reusing parts from other designs

What’s in the library​

We wanted to take this one step at a time. So for now, the library holds:

• A rectangle part. This is what we initially used to test-drive our solution.
• A sleeve part. This is the sleeve that was originally in the Brian block.
• A two-part-sleeve part. This is a combo of the two-part sleeve that was originally in the Bent block.
• A topsleeve part. This is the top part of the two-part sleeve.
• A undersleeve part. This is the under part of the two-part sleeve.

This is a modest start, as there’s obviously plenty of other things that would make a lot of sense in the library, such as collars, or cuffs, pockets, waistbands, and so on.

However, we wanted to start small and iron out any kinks before further extending the use of the library. You’ll also notice that merely by moving the various sleeves to the library, we already had to overhaul two foundational blocks, so it’s not like this was a small change.

Going forward, we will be looking to move more common parts into the library, with the ultimate goal that nobody should need to reinvent the wheel.

FreeSewing v4.4 has been released, and with it comes a new design: Sophie.

Sophie Slip Dress​

Sophie is a FreeSewing pattern for a slip dress designed and coded by JennaBarbara. Her first ever open source contribution 🎉.

Here’s what she had to say about it:

I like making and wearing slip dresses. They’re easy to put together, can be suitable for various levels of formality (from pyjamas to formalwear), and can be made from many different fabrics.

I decided I wanted to try drafting a slip using the Freesewing developer tools instead of paper, and the Sophie design was the result.

FreeSewing v4.3 has been released, and with it comes a new design: Percy.

Percy Puffy Pants​

Percy is a FreeSewing pattern for fall-front puffy shorts designed by Gawain who had the following to say about it:

I wanted a pair of shorts that had a fall front with a double row of buttons, a front pleat, and a flared bottom edge gathered down into a cuff. So I made one!

The front construction is a simplified, not-especially-accurate rendition of the fall front breeches common in the late 1700s and early 1800s. Most modern interpretations of this style have ornamental buttons and an elastic waistband or a hidden side zipper, but I wanted these ones to be real.

This pattern can be short or long, flared or unflared, and cuffed or uncuffed, so you can produce quite a wide variety of different pants. Only the fall front construction and the pockets are non-optional.

FreeSewing v4.2 is out, and it brings four new designs: Devon is a denim jacket, Jett jacket is a bomber jacket, Sarah Skirt Block is a basic skirt block, and Sunny is an 18th century split side skirt.

Devon Denim Jacket​

Desinged by Wouter – his 14th FreeSewing design for those keeping count – Devon is denim jacket pattern. Obviously, you can make it in other fabrics too, when we say denim jacket here, it’s more about the style of the garment.

Wouter has the following to say about it:

I Designed Devon because I had a nice denim jacket that I wanted to make available to others.

Devon is based on the Bent body block. Being a jacket, it has a considerable amount of ease added.

The design is inspired by denim jackets my partner has, and some patterns I’ve seen. Most denim jackets do not have set in sleeves, but since this is based on Bent, it does. It makes top stitching the armscye a little more challenging.

Jett (Bomber) Jacket​

Next up is Jett jacket, another jacket pattern in a timeless style, this time the so-called bomber jacket, or depending on the choice of fabrics and styles, it can also be a varsity aka letterman jacket.

Jett was designed and coded by Gawain CCBR, they had the following to say about it:

It’s highly recommended to take another jacket you like and compare the shoulder-to-shoulder and waist- to-armpit measurements against it before you start cutting.

This pattern is intended to fit the widest possible range of bodies, so it comes with a couple optional adjustments under the Fit options.

The bust dart/full bust adjustment is intended for people with breasts. There are two implementations available, one based on horizontal and vertical shifts, one based on rotations like a full bust adjustment for a paper pattern. The rotation-based one is better and you should probably use it.

The full belly adjustment operates under the assumption that the waist measurement is taken around the fullest part of your belly. If the fullest part of your belly is below the place you took the waist measurement, don’t worry about changing the rest of the vertical measurements to account for it - Jett makes the adjustment all the way down to the hem.

The full belly adjustment only takes effect if your waist measurement + the given waist ease is wider than the ease the pattern is already generating around your stomach. If you turn it on, but don’t see anything change, it’s because the pattern has enough ease that you don’t need the adjustment.

Sarah Skirt block​

Sarah is a skirt block based on the Aldrich drafting method. It was contributed by tduehr, the first design by their hand, but not the last (not event the last of this blog post).

Here’s what they had to say about it:

Sarah is the natural waist skirt block from W. Aldrich’s Metric Pattern Cutting for Women’s Wear, 6th Edition.

Blocks like this are used as the basic shape of garment designs. This can be sewn as is for a pencil skirt. Though, there are more options available in the Penelope pencil skirt.

*This is the first pattern I drafted for myself in different software as part of a collective attempt to learn CAD pattern drafting at my local maker space. (it’s the first in the book… probably not a coincidence). Several of the dimensions being magic and the curves being what ever looks good frustrated me intensely because they wouldn’t scale and the software does not contain a constraint solver to make up for that.

Sunny Skirt​

And finally (we’re going alphabetic here), we have a new skirt design named Sunny. This is a design that was discussed on our Discord server. The design is credited to halbmoki whereas tduehr wrote the code for it, in that casual I could, so I did fashion:

Sunny is an 18th century split side skirt. This came up in Discord and I thought it would be easy to code, so I did. This type of skirt was usually used as a petticoat. It can also be used as a skirt on its own. The side splits allow access for a pocket like Lucy.

We have just released FreeSewing v4.1, and by now you may be aware that a minor version bump typically means we have a new design. And that’s exactly what’s going on here, the Sabrina sports bra pattern is brand new.

Sabrina Sports Bra​

As Sabrina was designed & developed by Jonathan, so I’ll let him talk about it:

This update introduces Sabrina, a simple pull-on sports bra.

I designed Sabrina as a sports bra pattern. It provides light to medium support, but please note that the fit and compression depend heavily on the fabric used. The default ease is on the low/comfortable side. If you need or prefer more compression, consider increasing the stretch to 20% or more and using a fabric with a higher compression rating.

Sabrina is technically unisex. I made some prototypes using my own (male) body measurements and I like wearing them when I go running. They reduce chafing and chest bounce and provide comfortable compression.

Sabrina was developed from Breanna-based prototypes, but the actual construction is independent and straightforward. Essentially, it’s a rectangle with holes for the arms and head, plus a few darts to shape it to your body and reduce excess fabric. You can view the construction by enabling the ‘Base’ part in the Core settings under ‘Only Include Selected Pattern Parts’.

If you have previously made patterns with curved seams and stretchy fabric such as Shin or Bruce, you should find this bra straightforward to make.

I hope you find this pattern helpful.

Jonathan

Other changes​

For a full list of changes, you can (as always) check the CHANGELOG, but here are some highlights:

• Fixed a broken link in the welcome flow (oops!)
• We’ve added support for the ARCH D and ARCH E paper sizes
• We now support preview of the absolute value of snapped percentage options
• Fixed some translations issues in Octoplushy the octopus
• A whole bunch of improvements and fixes in the editor

However, as we run our website on the very latest changes, these have been introduced over the last couple of weeks, rather than since today.

We have launched the official FreeSewing forum at forum.freesewing.eu.

The idea that a good old forum would arguably be a better for for the FreeSewing community than the social network of the day is not new, it’s something that has always held true.

However, we were always reluctant to take on the additional burden of operating/maintaining/managing/moderating such a forum, because, well there’s only 24 hours in a day.

However, given the efforts we are making to keep our user’s data out of the reach of the US administration, it felt like the time was right to do it.

And so we did. The official FreeSewing forum lives at forum.freesewing.eu and you can (and should) use your FreeSewing account for authentication.

It’s a bit empty still, so don’t be shy and come say hello.

FreeSewing version 4 was released today, and we have migrated to our new website too.

This new major version of FreeSewing, version 4, has been in the works for a while, and I really wanted to get it out the door before sending out our Spring edition newsletter, so that’s exactly what I did.

As this is a major version, there are breaking changes, but we’ve really kept it to a minimum. There’s only one real breaking change:

• FreeSewing now requires NodeJS 20 or newer

In other words, we’ve dropped support for NodeJS 18, which will reach end of life at the end of next month.

A lot of work went into this new major release, especially in the realm of our frontend code, where we made a huge effort to make it more maintainable. This is the kind of thing that mostly happens under the hood, but will allow us to increase the project’s volatility and shorten our (non-major) release cycle.

What this means is that everything’s changed, and nothing has changed. I’ve compared it to your favorite restaurant moving across the street. It’s a different building, different kitchen, different everything. But your favorite waitress is still there serving that same food you’ve know and love.

That, in a nutshell, is FreeSewing v4.

👋 Bye bye Vercel/NextJS​

We have been using NextJS for several years now for the FreeSewing frontends. However, as I mentioned in an earlier edition of this newsletter, Vercel (the company behind NextJS) has revoked their sponsorship. This was nothing against FreeSewing, they’ve revoked all open source plans, but without their sponsorships, the cost of hosting our websites on Vercel is rather steep, and it was not sustainable for us to stay with them.

Furthermore, Vercel is also increasingly tying NextJS to their hosted offering, making it harder to just go elsewhere.

Since documentation is a critical (and large) part of both our website for makers and developers, we’ve decided to migrate to Docusaurus, which is highly optimized for documentation, but flexible enough that we can still do all the more advanced stuff that we need.

To improve maintainability and facilitate code reuse between our websites and new studio, we’ve abstracted all of our frontend logic into various components in our new @freesewing/react package which now underpins all our frontends.

This was a huge effort, and we are lagging behind with developer documentation, which is something which we’ll work on going forward.

Apart from that, I’m certain there will be some rough edges, but things should just work and if not, make sure to let us know.

With everything that is going on right now — gestures vaguely in the direction of the current US administration — it’s tempting to throw up our hands in despair, spend our days doomscrolling, or just check out somehow.

Unfortunately, that’s not going to cut it for we are way into uncharted territory here.

To put some distance between our users and the new US administration, we have moved everything that is potentially sensitive to brand new infrastructure in Europe, using European companies, rather than US-based companies. Specifically:

• We’ve moved our backend systems from DigitalOcean in the US to Scaleway in Germany
• We’ve moved our software repositories from GitHub in the US to Codeberg in Germany
• We’ve moved our transactional email service from AWS in the US to Scaleway in Germany (ongoing)
• We have put a de-facto freeze on our Instagram account, and recommend you follow our accounts on freesewing.social, our Mastodon instance hosted in Germany.
• We have re-visited our choice to use Discord as the de-facto place for the FreeSewing community, and have instead decided that here too we would step both to safeguard the data of our users, as well as embrace the open web. So we’ve created a forum for the FreeSewing community (more on that below).
• While freesewing.org will continue to work as expected, we will henceforth use freesewing.eu as our main domain name.

All of these changes are already active, although some need some time to percolate to completion.

None of this will impact you as a user of the site. So, you may find this overkill. But people trust us with their data, and we feel a moral obligation to safeguard that data even from a potential adversarial administration in the US.