In git I can use pass as a credential helper ^1.
[credential "https://github.com"]
helper = !pass git/rlue#github
Can I set up Mercurial/hg to also delegate password management to the pass tool?
Short answer
You can't
Longer answer
Mercurial has not concept of Git's credential helpers, but
a) because credentials may be needed only for pull|push, you can try (somehow) to emulate helpers with pre-* hooks, which just call pass (AFAICS, pass with filename without options just show file-content and nothing more)
b) Mercurial has such thing as Keyring Extension
uses services of the keyring library to securely save authentication passwords
and keyring, in turn, can support
additional keyring backend implementations available for other use cases
I.e. if you'll find|write backend for keyring, which will support pass directly or pass files, you can try to use Keyring Extension with new backend in "credential helper way"
PS: The latter thought is published on the rights of a dirty crazy idea, not a tested and|or at least implementable solution
Related
I have a Script Task with C# code written inside. The code is supposed to make several REST calls to get some data. The credentials (username, password) are hard-coded within the script. What are the things to do to make sure that my package is secured, and what is the best practice in similar scenarios, keeping in my mind that there is no possibility to use third-party API connectors, and Script Task is my only option ?
The best approach would be to move Login and Password from script task into Package parameters and declare Password as being sensitive. Thus Login and Password can be specified later at Package start or stored at Environment variables. Sensitive Password parameter means that it will be stored encrypted and cannot be dumped to a file, for example.
The following code sample shows how to use encrypted password in your script task
Dts.Variables["$Package::YourPassword"].GetSensitiveValue().ToString()
If you need to distribute your package without disclosing Login and Password, switch to another authentication method, perhaps, with certificates. Script Task source code cannot be obfuscated, so everyone who can download the package from the server has an opportunity to inspect your Script Task.
Here's an example:
https://phabricator.wikimedia.org/diffusion/EPFM/browse/master/?grep=BeforeFreeTextSubst
A Mediawiki extension where Hooks::run( 'PageForms::BeforeFreeTextSubst', ...) gets invoked but there's no other record or trace of where it's defined. If there was some mapping of strings/names to functions it would be registered somewhere else, and if it was a function name it should show up somewhere else.
I'm seeing this with a few other function hook events.
There isn't any "source definition" other than where the hook is run from. That is where the hook is defined; it may or may not actually be hooked onto anywhere. All the hook definition is is a name and a set of parameters that are passed to hook callbacks.
To help find out where the hook is actually used, you can use the (new) codesearch tool:
https://codesearch.wmflabs.org/extensions/?q=BeforeFreeTextSubst
(It looks like this one is not used by any extension that is in Wikimedia source control.)
Are you trying to find the functions that get called when the hook is run? The situation is a bit chaotic there. There are two mechanisms for defining hooks:
the $wgHooks global (this is the normal way of registering hooks);
and the Hooks::register method (sometimes used for registering hooks dynamically).
$wgHooks is normally set via the extension.json file, but can be set dynamically, too.
The quickest way to find out what hooks are registered is to run maintenance/shell.php and type in $wgHooks. This will miss hooks registered via the other method, and hooks which are conditionally registered (e.g. only for API calls), but it still works 99% of the time. Otherwise, you'll have to grep for it, as Sam said.
I did some research on MediaWiki hooks.
To the best of my knowledge, the only hook for adding/updating database tables is https://www.mediawiki.org/wiki/Manual:Hooks/LoadExtensionSchemaUpdates.
However, I need a hook that fires on installing a new extension. How do I achieve that? I'd like to execute a CREATE TABLE statement only once - when the extension is installed. Installing an extension doesn't require a MediaWiki update, which is why the above hook does not suit my needs.
EDIT
To clarify: I'm developing an extension that requires access to a custom table in the database. That's why I need to execute the CREATE TABLE statement whenever this extension is installed.
First: As you have noticed, there is no such hook. You will need to do the check for installed extensions by a cron job (if it's your server), or on, say, each 100th request to the wiki, using the job queue (if you are doing this in an extension).
From there, you have a few options, depending on if you need to catch every single extension, or just most of them:
Check for registered extensions, with something like: $registry = ExtensionRegistry::getInstance();$extensions = $registry->loaded();This will work extensions using the new style. For older versions, check the global variable $wgExtensionCredits for registered extensions. Note that nothing prevents an extensions from running without registering. In fact, there are a lot of extensions like that.
Parse LocalSettings.php, and check for old and new style extension loading with a regex. Very dirty, but it's actually the way e.g. the maintainance script getConfiguration.php does it. You need to check for lines like this:wfLoadExtension( 'FooBar' );and this:wfLoadExtensions( ['Foo', 'Bar'] );and this:require_once "$IP/extensions/Foo/Bar.php"; Note however that it is possible to use other directories for extensions, and that modern skins in fact behave like extensions too.
If you need to track a certain family of extensions, and you can make sure they all use Composer, the parse $IP/composer.json for installed extensions.
I did some more research (https://www.mediawiki.org/wiki/Manual:Update.php#Details) and found out that the LoadExtensionSchemaUpdates hook is exactly what I am looking for.
# Schema updates for update.php
$wgHooks['LoadExtensionSchemaUpdates'][] = 'fnMyHook';
function fnMyHook( DatabaseUpdater $updater ) {
$updater->addExtensionTable( 'tablename',
__DIR__ . '/table.sql' );
return true;
}
When running $ php update.php for the first time after installing the extension, the script executes the CREATE TABLE statement. Then, for consecutive executions, the update script just notes that the table already exists.
I did not find anything from the Mercurial hook documentation explaining how to get properties of the repository's hgrc file from a custom python hook.
As the documentation states that we have access to the full Mercurial API from hooks, I suppose this should be possible. But how?
Moreover I could not find a precise documentation on what are the objects (ui, repos, ...) passed in argument to the Mercurial hook.
Ok I find out the answer by myself.
This page gives some hints about the argument passed to the hook functions: https://www.mercurial-scm.org/wiki/MercurialApi#Reading_configuration_files
ui.config functions permit to read Mercurial configuration files, giving the section and property name.
I need to get all configuration settings (current role or all roles not matter) from Azure cscfg file. I want to do this because i dont want to get all values one by one via RoleEnvironment.GetConfigurationSettingValue(key) method.
Is there any way to do this?
Regards
The short answer is 'no' the RoleEnvironment does not support getting all the configuration setting values.
A slightly longer answer is that getting configuration settings from the role environment in the current implementation is done through a call to native code. The separation of Windows Azure Application from Windows Azure Configuration and the ability to swap settings on a running application is at the root of this somehow. This is done inside of msshrtmi.dll (which should mean something like Microsoft Shared Runtime Managed Interop). This is the only reference Microsoft.WindowsAzure.ServiceRuntime.dll has apart from standard references to .NET.
Here is the method call to native code (I have not gone further than this):
[MethodImpl(MethodImplOptions.Unmanaged, MethodCodeType=MethodCodeType.Native), SuppressUnmanagedCodeSecurity, DllImport("", EntryPoint="", CallingConvention=CallingConvention.StdCall, SetLastError=true)]
internal static extern unsafe int modopt(IsLong) modopt(CallConvStdcall) RdGetApplicationConfigurationSetting(ushort modopt(IsConst), ushort*);
It might seem like a slightly round-about way of doing it, but if you want to get the configurations for all the roles in a deployment you can use the management api.
Kudu has an API for this.
You get to Kudu like via App Services > Advanced Details > Go
https://{app-service-name}.scm.azurewebsites.net/
or
https://{app-service-name}-{slot-name}.scm.azurewebsites.net/
The Url for the settings API is:
https://{app-service-name}.azurewebsites.net/api/settings or https://{app-service-name}-{slot-name}.scm.azurewebsites.net/