Question: Disable storing of task arguments

[davocarli]

Hi, apologies if this is documented somewhere (I can't find it), but is there a quick way not to store the arguments that were passed to the celery task? Some of my tasks take in potentially sensitive information, and I would prefer not to have a permanent record of them inside of my database (I'm also looking at encrypting this information, but would prefer not to store it regardless).

[carnil]

It appears that this issue is associated with the CVE-2020-17495 CVE id.

[MartinFalatic]

Furthermore this is now being flagged by Pyup Safety (https://github.com/pyupio/safety-db):

╞══════════════════════════════════════════════════════════════════════════════╡
│ REPORT                                                                       │
│ checked 178 packages, using pyup.io's DB                                     │
╞════════════════════════════╤═══════════╤══════════════════════════╤══════════╡
│ package                    │ installed │ affected                 │ ID       │
╞════════════════════════════╧═══════════╧══════════════════════════╧══════════╡
│ django-celery-results      │ 1.2.1     │ <=1.2.1                  │ 38678    │
╞══════════════════════════════════════════════════════════════════════════════╡
│ Django-celery-results through 1.2.1 stores task results in the database.     │
│ Among the data it stores are the variables passed into the tasks. The        │
│ variables may contain sensitive cleartext information that does not belong   │
│ unencrypted in the database. See CVE-2020-17495.                             │
╘══════════════════════════════════════════════════════════════════════════════╛

[caleb15]

@auvipy @thedrow is this fixed? If do you know if this will be fixed in the next version?

[auvipy]

can you try the latest versions?

[peterfarrell]

Just to close the loop on this for those coming to this ticket, use the argsrepr and kwargsrepr support in Celery:

#154 (comment)

Django Celery Results uses these values when store results in the DB.

[G-Rath]

@auvipy I understand where people are coming from in terms of this ultimately being a thing for consumers to decide, but I think it's a reasonable ask for the default behaviour to be "more secure" meaning the "fix" for this CVE would be what's outlined in this comment.

Ultimately what I'm seeking is to be able to stick a patched version on the CVE as otherwise we have to handle this anytime we want to use this package in our applications.

I'm happy to help out with this where I can, though I'm not a Python developer so might require some help myself 😅

[auvipy]

current version is not affected by CVE, version belo 1.2 were effected :)

[auvipy]

and #154 (comment)

[G-Rath]

@auvipy the comment we've both linked to says that the setting currently isn't respected - are you saying that's now been changed?

Would you be able help me find the commit(s) that fixed this CVE?

[G-Rath]

@auvipy based on this comment, this CVE isn't fixed, it's just not accurately reflected in the safetydb.

The reason this is an issue for us is that it is present in the databases osv-detector pulls from, and it is a genuine security issue to have this enabled by default.

[auvipy]

I am OK with any help

[G-Rath]

Ill see what I can do, but as I said I'm very much not a Python Dev by trade so will likely need help.

It could be good to reopen this issue incase other Python developers are interested in helping.