search

EVE-SECURE / evedev-kb

Automatically exported from code.google.com/p/evedev-kb
0 stars 0 forks source link

Add a way of knowing if a mail was API verified on the "feed board" or was fetched from another #77

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
As title says.

Board1 fetches from Board2

Board2 fetches form Board3 and Board4

Board1 gets feed and can distinguish if it was API verified on Board2 or 
another board.

Board1 owner can now choose which boards to trust, and if to trust their 
trusted feeds.

Board1 can now show "API Verified" on mails fetched from Board2, but not 
mails fetched from Board3 and Board4 via Board2.

How does it sound?

Original issue reported on code.google.com by niels%ns...@gtempaccount.com on 8 Feb 2010 at 2:46

GoogleCodeExporter commented 9 years ago 
If we used a whole byte for this (which MySQL actually does for a boolean in 
current 
versions) we could have -1 = invalid, 0 = no API ID, >1 = distance to a board 
with an 
API ID from CCP. Invalid lets us mark an existing kill as invalid (See Issue 
48). The 
distance lets us decide that we only want to fetch kills from a trusted board, 
or 
from boards that a trusted board trusts (or even further).

We could also have negatives that are the distance to a board that deleted a 
kill. 
You can decide to delete mails that trusted boards delete or also delete those 
that 
trusted of trusted delete.

Balancing those, you could say delete all mails from a lower tier of trust. If 
trusted of trusted says delete a kill that came from trusted then you keep it. 
If 
trusted says delete a kill that came from trusted of trusted then you delete 
it. If 
trusted has a kill from the API that trusted of trusted deleted, then you 
reinstate 
it.

Original comment by kovellia on 10 Feb 2010 at 10:03

GoogleCodeExporter commented 9 years ago 
Sounds like a really good idea. Get it working :)

Original comment by niels%ns...@gtempaccount.com on 10 Feb 2010 at 10:35

GoogleCodeExporter commented 9 years ago 
A problem with this scheme is timing. Board2 could fetch a kill from Board3. 
Board1 
fetches from Board2, doesn't trust the API ID as it's from Board3 so doesn't 
use it. 
Board2 then fetches it from CCP and marks the kill appropriately. Board1 never 
sees 
that the kill is now trusted.

I think for this to work to work yet another field is needed, a last-modified 
timestamp. You now fetch all kills added or modified since the last fetch 
(which 
helps the deleted kill idea). The only modifications that can happen are 
deletion, 
modification of trust, or addition of an api id. The last requires a complete 
kill 
(or a new hash scheme) but the others can be just the new trust status.

Original comment by kovellia on 10 Mar 2010 at 4:48

GoogleCodeExporter commented 9 years ago 
Sounds good to me. But yes, some clever killmail id scheme would be nice.

How about a simple hash over trim(killmail)?

Original comment by niels%ns...@gtempaccount.com on 11 Mar 2010 at 2:05

GoogleCodeExporter commented 9 years ago 
trim(killmail) wouldn't be reliable as the order of involved parties and items 
can 
change, capitalisation changes, and item names can change over longer periods. 
A hash 
would thus need some parsing to create. Boards at both ends need to process the 
entire 
kill to generate or check the hash, and it would be added to every feed, so it 
makes 
sense to store the hash. I think the scheme used now would do.

md5(time, victim, ship, system, damage taken, [involved pilot, damage done]+)

Original comment by kovellia on 13 Mar 2010 at 5:30

GoogleCodeExporter commented 9 years ago 
Attached is a fast way of creating this hash.

Pulls out info from the raw mail, can be inserted just before parser.
But we need these hashes in the db.

Original comment by niels%ns...@gtempaccount.com on 21 Mar 2010 at 1:57

Attachments:

GoogleCodeExporter commented 9 years ago 
I have code running to create and store the hashes and trust levels. At the 
moment it 
sets every kill to a trust of 0 or -1 on deletion. The feed shows hash (saving 
a tiny 
bit more time) and trust on each mail.

Still needed is the update script that creates the table, and modifications to 
the 
feedfetcher to add acceptable trust levels.

Original comment by kovellia on 23 May 2010 at 2:34

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Now partly done with r680, r684, and r687. Hashes, time and trust are stored. 
Hashes 
and time are used to check uniqueness. Feed sends and fetches hash, trust and 
api id 
information. Now the feed interface needs rewriting to include the concept of 
trust.

Feedurl : Trust level (yes/no?) : API kills only (which will include fetches 
from 
trusted boards) : Fetch (yes/no) (used only by the admin page, as now.)

Hmm. I didn't add the last modified timestamp. Is this worth adding? That would 
just 
show deleted kills and kills with an api id added. I'm very hesitant to 
automatically 
delete kills when another board does, trusted or not.

Original comment by kovellia on 28 May 2010 at 1:31

GoogleCodeExporter commented 9 years ago 
Marking as done. Cascading deletes may still be added for 3.2. That function 
does not depend on changes to the trust/verified/hash functions or vice versa.

More testing would be good but that's up to the extensive QA team.

Original comment by kovellia on 14 Jun 2010 at 12:07