Publish a new package, loguru-hardened, with security focussed defaults

[bneijt]

Introduce a separate script that will override a few files to harden loguru defaults and build a loguru-hardened package, then revert the changes using git.

[Delgan]

I don't know why 3.13 build fails, maybe try rebasing (a few libraries were updated since then)?

[trim21]

if it's serialized be default, should we also remove level time from default format?

[bneijt]

if it's serialized be default, should we also remove level time from default format?

I don't follow, could you give a code example of what you mean or explain further?

[trim21]

if it's serialized be default, should we also remove level time from default format?

I don't follow, could you give a code example of what you mean or explain further?

from

LOGURU_FORMAT = env(
    "LOGURU_FORMAT",
    str,
    "<green>{time:YYYY-MM-DD HH:mm:ss.SSS}</green> | "
    "<level>{level: <8}</level> | "
    "<cyan>{name}</cyan>:<cyan>{function}</cyan>:<cyan>{line}</cyan> - <level>{message}</level>",
)

to

LOGURU_FORMAT = env("LOGURU_FORMAT", str, "{message}")

[bneijt]

I also mentioned loguru-hardened in the README, but I could not find a release action configured, so I'm not sure how to make sure hardened is also released when a new release is created.

[Delgan]

Indeed, since there is no Github Action, I need to do it manually for now.

[bneijt]

I could open up another pr with release workflows if you would like that. I don't know what currently goes into the manual release actions, but it might be a nice setup to simplify maintenance.

[Delgan]

@bneijt Thanks for the proposal. If you're familiar with release automation via Github Actions, your help is most welcome. I'd like to replace manual release management.

Also sorry for not having yet merged this PR, but it seems it will be incompatible with #1140. I need to check how to create loguru-hardened without setup.py.

[trim21]

just use a Python script change project.name in new pyproject.toml file

[trim21]

i can help write a ci file

[Delgan]

@trim21 Yes, I suppose this should be straightforward. Unfortunately, this PR will need to be updated, though.

[trim21]

consider merge 1140 first maybe....

[Delgan]

I finally fixed CI for Python 3.5 and 3.13, can you try rebasing the PR please?

[trim21]

I have a question about this, what if a package I'm using require loguru, and my application require this package, and use loguru-hardened? it will conflict

my app
├── package
│   └── loguru
└── loguru-hardened

a possible solution here would be, instead of new package, add a extra，this extra require a new package loguru-hardened, but it do nothing.

Then in loguru, we just check if package loguru-hardened exists, and if it exists, use hardened default.

so instead of install loguru-hardened and cause conflect, users can just install loguru[hardened], and works fine with package require loguru

try:
    import loguru._hardened
    HARDENED_ENABLED = True
except ImportError:
    HARDENED_ENABLED = False

[bneijt]

I have a question about this, what if a package I'm using require loguru, and my application require this package, and use loguru-hardened? it will conflict

Yes, there will be a conflict which needs to be solved by uninstalling or ignoring the loguru package in environments that require you to use a hardened version instead.

The proposed workaround of using an extra won’t work because the reason for having this package is to facilitate environments where static code analysis like sonarqube flag loguru for being difficult to use in a secure way.

Which means that we can’t have loguru installed.

Next week I will find some time to create a hood example of how to use loguru hardened in those situations and explain how to deal with oackages that require loguru.

[trim21]

Yes, there will be a conflict which needs to be solved by uninstalling or ignoring the loguru package in environments that require you to use a hardened version instead.

I don't think this is a solution...

in some case you don't have control which package will be installed first, loguru or loguru-hardened, which mean it's possible loguru override loguru-hardened, not what we are expecting, loguru-hardened over loguru.

The proposed workaround of using an extra won’t work because the reason for having this package is to facilitate environments where static code analysis like sonarqube flag loguru for being difficult to use in a secure way.

Which means that we can’t have loguru installed.

That's false positive problem of static code analysi themselve, right?
It doesn't make sence if you have env var LOGURU_SERIALIZE=True, you won't (can't) have multiple line log message in json

[bneijt]

That's false positive problem of static code analysi themselve, right? It doesn't make sence if you have env var LOGURU_SERIALIZE=True, you won't (can't) have multiple line log message in json

Yes and no.. it is not a false positive that “the default don’t protect against line injection properly”, but you are right that that is a bad mark in the first place because that same reasoning should flag Python itself (logging has the same issue) ;)

[trim21]

Yes and no.. it is not a false positive that “the default don’t protect against line injection properly”, but you are right that that is a bad mark in the first place because that same reasoning should flag Python itself (logging has the same issue) ;)

So with extra, the default has been changed, right?

or no matter how loguru changed, it will just flag loguru anyway?