Enhancement: service aliases to workaround case-sensetive ServiceNames about assemblyline HOT 7 OPEN

Perhaps a quick resolution might be a "try again" approach by checking for the case-sensitive name first. Then if False, instead of failing, check case-insensitive. This might preserve the backward compatibility of allowing case-sensitive service names when there is duplication.

from assemblyline.

How far would this need of service name aliasing need to go exactly? Just for ingests/submits to the system?

from assemblyline.

That would cover my use case. I think the better target might be the API endpoints to cover all integrations. I can't recall if there are any other queries that take the service name, but I'd consider those as well if it's not a heavy lift.

from assemblyline.

Can we tackle this a completely different way and just reject the API call if you've provided the name of a service that does not exist? That way, we dont have to implement a list of service aliases and manitain that list and if you submit a file to a service that does not exist, the call will be rejected and you will know that you've messed up. Cause in the end, your in a the same boat if you typo the name even when aliases exists...

from assemblyline.

My use case was case-sensitivity conflicts, as we have a client application that uses lowercase virustotal, metadefender, etc. If you're checking if a service exists, than for this case, I expect it could replace it. For example:

servicename = getServiceName(servicename)

def getServiceName(servicename):
    for service in services:
        if service.lower() == servicename.lower():
            return service
    return None

I expect a replace of spaces, underscores, dashes could be handled similarly if desired. A full alias beyond that would probably be a lot more involved. @markus-lassfolk what was your use case? Not sure if I'll use it or not, but I did like the trick of being able to submit a binary without running a service for the purpose of just adding it to the archive for retro hunting.

from assemblyline.

It was mostly that it felt strange to have to memorize the casing for all services to call them.
And then using casing to distinguish between two different services sharing the same name feels prone for error.
My imagination is too limited to find a scenario where I would like to call MetaDefender or MEtaDefender or metadefender and consider that 3 different services in the backend.

from assemblyline.

The only reason for them being case sensitive is that we've used the service name as the document key in elastic and the document key is case sensitive there. And now we're kind of stuck with it for legacy reasons. Even if we where to provide service Aliases this would only apply at input because if you where to do searches for those services results afterwards you'd still have to use their case-sensitive value... That is kind of why I'm reluctant to this change as I am right now without a solution to move to case-insensitive everywhere without reindexing all the data on currently running systems.

from assemblyline.