git-annex/Types/Group.hs

{- git-annex repo groups
 -
 - Copyright 2012-2024 Joey Hess <id@joeyh.name>
 -
 - Licensed under the GNU AGPL version 3 or higher.
 -}

module Types.Group (
	Group(..),
	fromGroup,
	toGroup,
	GroupMap(..),
	emptyGroupMap
) where

import Types.UUID
import Utility.FileSystemEncoding
import Annex.Balanced

import qualified Data.Map as M
import qualified Data.Set as S
import qualified Data.ByteString as S

newtype Group = Group S.ByteString
	deriving (Eq, Ord, Show, Read)

fromGroup :: Group -> String
fromGroup (Group g) = decodeBS g

toGroup :: String -> Group
toGroup = Group . encodeBS

data GroupMap = GroupMap
	{ groupsByUUID :: M.Map UUID (S.Set Group)
	, uuidsByGroup :: M.Map Group (S.Set UUID)
	, balancedPickerByGroup :: M.Map Group BalancedPicker
	}

emptyGroupMap :: GroupMap
emptyGroupMap = GroupMap M.empty M.empty M.empty
group, ungroup: New commands to indicate groups of repositories. 2012-10-01 19:12:04 +00:00			`{- git-annex repo groups`
			`-`
use hmac in balanced preferred content This deals with the possible security problem that someone could make an unusually low UUID and generate keys that are all constructed to hash to a number that, mod the number of repositories in the group, == 0. So balanced preferred content would always put those keys in the repository with the low UUID as long as the group contains the number of repositories that the attacker anticipated. Presumably the attacker than holds the data for ransom? Dunno. Anyway, the partial solution is to use HMAC (sha256) with all the UUIDs combined together as the "secret", and the key as the "message". Now any change in the set of UUIDs in a group will invalidate the attacker's constructed keys from hashing to anything in particular. Given that there are plenty of other things someone can do if they can write to the repository -- including modifying preferred content so only their repository wants files, and numcopies so other repositories drom them -- this seems like safeguard enough. Note that, in balancedPicker, combineduuids is memoized. 2024-08-10 20:32:54 +00:00			`- Copyright 2012-2024 Joey Hess <id@joeyh.name>`
group, ungroup: New commands to indicate groups of repositories. 2012-10-01 19:12:04 +00:00			`-`
update licenses from GPL to AGPL This does not change the overall license of the git-annex program, which was already AGPL due to a number of sources files being AGPL already. Legally speaking, I'm adding a new license under which these files are now available; I already released their current contents under the GPL license. Now they're dual licensed GPL and AGPL. However, I intend for all my future changes to these files to only be released under the AGPL license, and I won't be tracking the dual licensing status, so I'm simply changing the license statement to say it's AGPL. (In some cases, others wrote parts of the code of a file and released it under the GPL; but in all cases I have contributed a significant portion of the code in each file and it's that code that is getting the AGPL license; the GPL license of other contributors allows combining with AGPL code.) 2019-03-13 19:48:14 +00:00			`- Licensed under the GNU AGPL version 3 or higher.`
group, ungroup: New commands to indicate groups of repositories. 2012-10-01 19:12:04 +00:00			`-}`

			`module Types.Group (`
newtype Group to ByteString This may speed up queries for things in groups, due to Eq and Ord being faster. 2019-01-09 19:00:43 +00:00			`Group(..),`
			`fromGroup,`
			`toGroup,`
add --ingroup limit 2012-10-08 19:18:58 +00:00			`GroupMap(..),`
			`emptyGroupMap`
group, ungroup: New commands to indicate groups of repositories. 2012-10-01 19:12:04 +00:00			`) where`

			`import Types.UUID`
newtype Group to ByteString This may speed up queries for things in groups, due to Eq and Ord being faster. 2019-01-09 19:00:43 +00:00			`import Utility.FileSystemEncoding`
use hmac in balanced preferred content This deals with the possible security problem that someone could make an unusually low UUID and generate keys that are all constructed to hash to a number that, mod the number of repositories in the group, == 0. So balanced preferred content would always put those keys in the repository with the low UUID as long as the group contains the number of repositories that the attacker anticipated. Presumably the attacker than holds the data for ransom? Dunno. Anyway, the partial solution is to use HMAC (sha256) with all the UUIDs combined together as the "secret", and the key as the "message". Now any change in the set of UUIDs in a group will invalidate the attacker's constructed keys from hashing to anything in particular. Given that there are plenty of other things someone can do if they can write to the repository -- including modifying preferred content so only their repository wants files, and numcopies so other repositories drom them -- this seems like safeguard enough. Note that, in balancedPicker, combineduuids is memoized. 2024-08-10 20:32:54 +00:00			`import Annex.Balanced`
group, ungroup: New commands to indicate groups of repositories. 2012-10-01 19:12:04 +00:00
			`import qualified Data.Map as M`
			`import qualified Data.Set as S`
newtype Group to ByteString This may speed up queries for things in groups, due to Eq and Ord being faster. 2019-01-09 19:00:43 +00:00			`import qualified Data.ByteString as S`
group, ungroup: New commands to indicate groups of repositories. 2012-10-01 19:12:04 +00:00
newtype Group to ByteString This may speed up queries for things in groups, due to Eq and Ord being faster. 2019-01-09 19:00:43 +00:00			`newtype Group = Group S.ByteString`
git-annex sim command is working Had to add Read instances to Key and NumCopies and some other similar types. I only expect to use those in serializing a sim. Of course, this risks that implementation changes break reading old data. For a sim, that would not be a big problem. 2024-09-12 20:07:44 +00:00			`deriving (Eq, Ord, Show, Read)`
newtype Group to ByteString This may speed up queries for things in groups, due to Eq and Ord being faster. 2019-01-09 19:00:43 +00:00
			`fromGroup :: Group -> String`
			`fromGroup (Group g) = decodeBS g`

			`toGroup :: String -> Group`
			`toGroup = Group . encodeBS`
group, ungroup: New commands to indicate groups of repositories. 2012-10-01 19:12:04 +00:00
status: display repository groups 2012-10-02 17:45:30 +00:00			`data GroupMap = GroupMap`
			`{ groupsByUUID :: M.Map UUID (S.Set Group)`
			`, uuidsByGroup :: M.Map Group (S.Set UUID)`
use hmac in balanced preferred content This deals with the possible security problem that someone could make an unusually low UUID and generate keys that are all constructed to hash to a number that, mod the number of repositories in the group, == 0. So balanced preferred content would always put those keys in the repository with the low UUID as long as the group contains the number of repositories that the attacker anticipated. Presumably the attacker than holds the data for ransom? Dunno. Anyway, the partial solution is to use HMAC (sha256) with all the UUIDs combined together as the "secret", and the key as the "message". Now any change in the set of UUIDs in a group will invalidate the attacker's constructed keys from hashing to anything in particular. Given that there are plenty of other things someone can do if they can write to the repository -- including modifying preferred content so only their repository wants files, and numcopies so other repositories drom them -- this seems like safeguard enough. Note that, in balancedPicker, combineduuids is memoized. 2024-08-10 20:32:54 +00:00			`, balancedPickerByGroup :: M.Map Group BalancedPicker`
status: display repository groups 2012-10-02 17:45:30 +00:00			`}`
add --ingroup limit 2012-10-08 19:18:58 +00:00
			`emptyGroupMap :: GroupMap`
use hmac in balanced preferred content This deals with the possible security problem that someone could make an unusually low UUID and generate keys that are all constructed to hash to a number that, mod the number of repositories in the group, == 0. So balanced preferred content would always put those keys in the repository with the low UUID as long as the group contains the number of repositories that the attacker anticipated. Presumably the attacker than holds the data for ransom? Dunno. Anyway, the partial solution is to use HMAC (sha256) with all the UUIDs combined together as the "secret", and the key as the "message". Now any change in the set of UUIDs in a group will invalidate the attacker's constructed keys from hashing to anything in particular. Given that there are plenty of other things someone can do if they can write to the repository -- including modifying preferred content so only their repository wants files, and numcopies so other repositories drom them -- this seems like safeguard enough. Note that, in balancedPicker, combineduuids is memoized. 2024-08-10 20:32:54 +00:00			`emptyGroupMap = GroupMap M.empty M.empty M.empty`